Современное представление о REST сильно отличается от концепции архитектурного стиля, описанной в диссертации его создателя, Роя Филдинга. В этой статье разберемся, как ограничения REST понимал их автор.
Это адаптированный перевод статьи Roy Fielding’s REST dissertation Оле Бегеманна, разработчика и автора учебника Advanced Swift. Повествование ведется от лица автора оригинала.
Прежде, чем перейти к ограничениям, рассмотрим несколько фактов о REST:
Главный барьер для реализации этого принципа, по словам Филдинга — файлы cookie. Он называет их «досадным несоответствием между идеалами REST и реальностью HTTP».
То, под каким углом Филдинг рассматривает вопрос кэшируемости в своей диссертации, сильно отличается от современного взгляда на REST. В частности, он уделяет много внимания кэшируемости, масштабируемости и прокси, но почти не рассматривает метод POST vs. PUT vs. PATCH.
Ресурс — это концептуальное отображение набора конкретных сущностей. Например, «сегодняшняя погода» является достоверным ресурсом, даже несмотря на то, что информация, которая в нем отображает, меняется ежедневно. Каждый ресурс имеет уникальный идентификатор — чаще всего это URI.
Манипулирование ресурсами через представления. Поскольку ресурсы могут быть абстрактными понятиями, они никогда не передаются по сети напрямую: сервер и клиент обмениваются их представлениями. В идеальном мире сервер должен предлагать несколько представлений одного и того же ресурса (например, для JSON и XML), а клиент — сообщать серверу, с каким представлением он может работать.
habr.com
Это адаптированный перевод статьи Roy Fielding’s REST dissertation Оле Бегеманна, разработчика и автора учебника Advanced Swift. Повествование ведется от лица автора оригинала.
Прежде, чем перейти к ограничениям, рассмотрим несколько фактов о REST:
- REST почти столько же лет, сколько вебу Диссертация Филдинга, которая легла в основу этой статьи, опубликована в 2000 году, а идеи для нее он начал формулировать еще в 1994 году. Вероятно, от этой даты стоит отсчитывать историю REST.
- REST появился сразу после HTTP. В 1994 году Филдинг начал работать в консорциуме World Wide Web, где занимался разработкой спецификаций HTTP 1.0, HTTP 1.1 и URI, а также участвовал в создании веб-сервера Apache. REST был его сайд-проектом.
- REST — это архитектура сети. Он не имеет отношения к веб-службам — например, к машиночитаемым API, возвращающим JSON или XML. В своей диссертации Филдинг даже не упоминает веб-API.
- REST — это прежде всего описание архитектуры сети. Концепция предполагает, что вся сеть должна быть RESTful. Изначально REST был разработан именно для указания на архитектуру сети (в соответствии со спецификацией HTTP 1.1 ).
Сначала REST назывался «объектная модель HTTP», но такое определение часто приводило к неправильному толкованию — многие разработчики считали его моделью реализации HTTP-сервера.
Архитектурные ограничения
REST определяется ограничениями и любая коммуникационная архитектура, которая хочет называться RESTful, должна им соответствовать. Их полный список можно найти в «Википедии» — в этой статье остановимся на ограничениях, которые кажутся мне наиболее важными.Отсутствие сохранения состояния
Это ограничение предполагает, что с одной стороны, каждый запрос содержит достаточно информации, чтобы сервер его понял. С другой, он не может пользоваться преимуществом любого сохраненного на сервере контекста. Состояние сеанса при этом полностью сохраняется на клиенте. Это делает приложение надежнее, а масштабирование — проще.Главный барьер для реализации этого принципа, по словам Филдинга — файлы cookie. Он называет их «досадным несоответствием между идеалами REST и реальностью HTTP».
Кэшируемость
И запросы к серверу, и его ответы должны содержать данные о кэшируемости. В случае, если ответ помечен как кэшируемый, клиент (или любой узел, расположенный между сервером и клиентом) может использовать данные для следующих запросов.То, под каким углом Филдинг рассматривает вопрос кэшируемости в своей диссертации, сильно отличается от современного взгляда на REST. В частности, он уделяет много внимания кэшируемости, масштабируемости и прокси, но почти не рассматривает метод POST vs. PUT vs. PATCH.
Ресурсы и представления
Идентификация ресурсов. Ресурсы — это ключевая абстракция REST. Она противоречит ранним спецификациям интернета, в которых термин «документ» использовался для обозначения отдельной единицы контента. Ресурс — более общее понятие, чем документ. Например, наличие URI для документа подразумевает, что он существует, в то время как идентификатор ресурса может быть действительным еще до того, как ресурс начнет существовать. Например, клиент может передать URI несуществующего ресурса для его создания.Ресурс — это концептуальное отображение набора конкретных сущностей. Например, «сегодняшняя погода» является достоверным ресурсом, даже несмотря на то, что информация, которая в нем отображает, меняется ежедневно. Каждый ресурс имеет уникальный идентификатор — чаще всего это URI.
Манипулирование ресурсами через представления. Поскольку ресурсы могут быть абстрактными понятиями, они никогда не передаются по сети напрямую: сервер и клиент обмениваются их представлениями. В идеальном мире сервер должен предлагать несколько представлений одного и того же ресурса (например, для JSON и XML), а клиент — сообщать серверу, с каким представлением он может работать.
Самодокументируемые сообщения
Каждое сообщение содержит достаточно информации, чтобы описать, как обрабатывать сообщение. Например, информация о типе носителя должна содержаться в каждом сообщении. Кроме того, каждое сообщение полностью идентифицирует ресурс, к которому оно относится. Это не относится к первым версиям HTTP. В них заголовок HTTP не содержал имени хоста — предполагалось, что существует соответствие 1: 1 между IP-адресами и именами хостов.Гипермедиа как двигатель состояния приложения (AKA HATEOAS)
Основная идея HATEOAS заключается в том, что RESTful серверы и клиенты не должны полагаться на жестко запрограммированный интерфейс (который они заранее согласовали через отдельный канал). Вместо этого сервер должен отправлять набор URI, которые представляют собой варианты перехода между состояниями, из которых клиент может выбрать нужный. Именно так работают веб-браузеры.Трудно представить, как реализовать этот принцип для веб-сервисов, где две виртуальные машины обмениваются данными друг с другом без участия человека. Как можно разработать клиент для конкретного API без строгого кодирования информации об ожидаемых типах ресурсов? В своей диссертации Филдинг не дает ответа на этот вопрос. В 2008 году в своем блоге он написал, что API-интерфейсы должны управляться гипертекстом, чтобы считаться RESTful:
Почему никто не понимает REST
Современное представление о REST сильно отличается от концепции архитектурного стиля, описанной в диссертации его создателя, Роя Филдинга. В этой статье разберемся, как ограничения REST понимал их...
habr.com