Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Архитектурный стиль для клиент-серверных приложений
Architectural style for client server applications
REST (Representational State Transfer – представительное состояние передачи) – это архитектурный стиль программного обеспечения, разработанный для управления проектированием и разработкой архитектуры Всемирной паутины. REST определяет набор ограничений, описывающих поведение архитектуры распределенной гипермедиа-системы интернет-масштаба, такой как Веб. Архитектурный стиль REST делает акцент на единообразных интерфейсах, независимом развертывании компонентов, масштабируемости взаимодействий между ними и создании многоуровневой архитектуры для повышения эффективности кэширования, снижения воспринимаемой пользователем задержки, обеспечения безопасности и инкапсуляции устаревших систем. REST широко используется в индустрии программного обеспечения для создания надежных, без сохранения состояния веб-приложений. Приложение, соответствующее архитектурным ограничениям REST, может быть неформально описано как RESTful, хотя этот термин чаще ассоциируется с разработкой HTTP-API и общепринятыми лучшими практиками в отношении "глаголов" (HTTP-методов), на которые реагирует ресурс, что мало связано с первоначальной формулировкой REST и часто даже противоречит этой концепции.
REST (representational state transfer) is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of a distributed, Internet scale hypermedia system, such as the Web, should behave. The REST architectural style emphasises uniform interfaces, independent deployment of components, the scalability of interactions between them, and creating a layered architecture to promote caching to reduce user perceived latency, enforce security, and encapsulate legacy systems. REST has been employed throughout the software industry to create stateless, reliable web based applications. An application that adheres to the REST architectural constraints may be informally described as RESTful, although this term is more commonly associated with the design of HTTP based APIs and what are widely considered best practices regarding the "verbs" (HTTP methods) a resource responds to while having little to do with REST as originally formulated—and is often even at odds with the concept.
Принцип
Термин «передача состояния представления» был введен и определен в 2000 году ученым-компьютерщиком Роем Филдингом в его докторской диссертации. Это означает, что сервер будет отвечать представлением ресурса (в настоящее время это чаще всего HTML, XML или JSON документ), и этот ресурс будет содержать гипермедийные ссылки, переходя по которым можно изменить состояние системы. Любой такой запрос, в свою очередь, получит представление ресурса, и так далее. Важным следствием является то, что необходимо знать только идентификатор первого запрошенного ресурса, а все остальные идентификаторы будут обнаружены в процессе работы. Это означает, что эти идентификаторы могут меняться без необходимости предварительного уведомления клиента и что между клиентом и сервером существует слабая связанность.
The term representational state transfer was introduced and defined in 2000 by computer scientist Roy Fielding in his doctoral dissertation. It means that a server will respond with the representation of a resource (today, it will most often be an HTML, XML or JSON document) and that resource will contain hypermedia links that can be followed to make the state of the system change. Any such request will in turn receive the representation of a resource, and so on. An important consequence is that the only identifier that needs to be known is the identifier of the first resource requested, and all other identifiers will be discovered. This means that those identifiers can change without the need to inform the client beforehand and that there can be only loose coupling between client and server.
История
Веб начал входить в повседневное использование в 1993–1994 годах, когда стали появляться веб-сайты общего назначения. В то время существовало лишь фрагментарное описание архитектуры Веба, и в отрасли ощущалось давление с целью согласования единых стандартов для протоколов веб-интерфейсов. Например, в протокол обмена данными (HTTP) было добавлено несколько экспериментальных расширений для поддержки прокси-серверов, и предлагались новые расширения, но возникла потребность в формальной веб-архитектуре, которая позволила бы оценить влияние этих изменений. Рабочие группы W3C и IETF совместно приступили к разработке формальных описаний трех основных стандартов Веба: URI, HTTP и HTML. Рой Филдинг принимал участие в создании этих стандартов (в частности, HTTP 1.0 и 1.1, а также URI), и в течение следующих шести лет он разработал архитектурный стиль REST, проверяя его ограничения на протокольных стандартах Веба и используя его как инструмент для определения архитектурных улучшений и выявления архитектурных несоответствий. Филдинг определил REST в своей докторской диссертации 2000 года "Архитектурные стили и проектирование программных архитектур, основанных на сетях" в UC Irvine. Для создания архитектурного стиля REST Филдинг выявил требования, применимые при создании приложения, основанного на глобальной сети, такие как необходимость низкого порога входа для обеспечения широкого распространения. Он также изучил множество существующих архитектурных стилей для сетевых приложений, определив, какие функции являются общими для других стилей, такие как кэширование и клиент-серверная архитектура, а какие уникальны для REST, например, концепция ресурсов. Филдинг стремился как классифицировать существующую архитектуру текущей реализации, так и определить, какие аспекты следует считать ключевыми для поведенческих и эксплуатационных требований Веба. По своей природе архитектурные стили независимы от какой-либо конкретной реализации, и хотя REST был создан в рамках разработки веб-стандартов, реализация Веба не всегда соответствует всем ограничениям архитектурного стиля REST. Несоответствия могут возникать из-за незнания или упущения, но наличие архитектурного стиля REST позволяет выявлять их до того, как они будут стандартизированы. Например, Филдинг определил встраивание информации о сессии в URI как нарушение ограничений REST, которое может негативно сказаться на совместном кэшировании и масштабируемости сервера. HTTP-куки также нарушают ограничения REST, поскольку они могут рассинхронизироваться с состоянием приложения в браузере, что делает их ненадежными; кроме того, они содержат непрозрачные данные, которые могут вызывать опасения в отношении конфиденциальности и безопасности.
The Web began to enter everyday use in 1993–1994, when websites for general use started to become available. At the time, there was only a fragmented description of the Web's architecture, and there was pressure in the industry to agree on some standard for the Web interface protocols. For instance, several experimental extensions had been added to the communication protocol (HTTP) to support proxies, and more extensions were being proposed, but there was a need for a formal Web architecture with which to evaluate the impact of these changes. The W3C and IETF working groups together started work on creating formal descriptions of the Web's three primary standards: URI, HTTP, and HTML. Roy Fielding was involved in the creation of these standards (specifically HTTP 1.0 and 1.1, and URI), and during the next six years he created the REST architectural style, testing its constraints on the Web's protocol standards and using it as a means to define architectural improvements — and to identify architectural mismatches. Fielding defined REST in his 2000 PhD dissertation "Architectural Styles and the Design of Network based Software Architectures" at UC Irvine. To create the REST architectural style, Fielding identified the requirements that apply when creating a world wide network based application, such as the need for a low entry barrier to enable global adoption. He also surveyed many existing architectural styles for network based applications, identifying which features are shared with other styles, such as caching and client–server features, and those which are unique to REST, such as the concept of resources. Fielding was trying to both categorise the existing architecture of the current implementation and identify which aspects should be considered central to the behavioural and performance requirements of the Web. By their nature, architectural styles are independent of any specific implementation, and while REST was created as part of the development of the Web standards, the implementation of the Web does not obey every constraint in the REST architectural style. Mismatches can occur due to ignorance or oversight, but the existence of the REST architectural style means that they can be identified before they become standardised. For example, Fielding identified the embedding of session information in URIs as a violation of the constraints of REST which can negatively affect shared caching and server scalability. HTTP cookies also violated REST constraints because they can become out of sync with the browser's application state, making them unreliable; they also contain opaque data that can be a concern for privacy and security.
Единый интерфейс
Ограничение единого интерфейса фундаментально для проектирования любой RESTful-системы.
The uniform interface constraint is fundamental to the design of any RESTful system.