Rest что это такое
Основы REST: теория и практика
Авторизуйтесь
Основы REST: теория и практика
REST, Representational State Transfer, является архитектурным стилем для обеспечения стандартов между компьютерными системами в сети, что облегчает для систем обмен данными друг с другом. Системы, отвечающие требованиям REST и часто называемые RESTful, характеризуются тем, что не имеют сохранения состояния и разделяют интересы клиента и сервера. Мы рассмотрим, что означают эти термины и почему они являются полезными для услуг в Интернете.
Разделение клиента и сервера
В архитектурном стиле REST реализация клиента и реализация сервера могут быть выполнены независимо друг от друга. Это означает, что код на стороне клиента может быть изменён в любое время без ущерба для работы сервера, а код на стороне сервера может быть изменён без влияния на работу клиента.
До тех пор, пока каждая сторона знает, какой формат сообщений следует направлять другой стороне, они могут храниться модульно и раздельно. Отделяя задачи пользовательского интерфейса от задач хранения данных, мы повышаем гибкость интерфейса между платформами и улучшаем расширяемость за счёт упрощения компонентов сервера. Кроме того, разделение позволяет каждому компоненту развиваться независимо.
Используя интерфейс REST, различные клиенты попадают в одни и те же конечные точки REST, выполняют те же действия и получают одинаковые ответы.
Отсутствие сохранения состояния
Системы, которые следуют парадигме REST, не имеют сохранения состояния, что означает, что серверу не нужно знать о состоянии клиента и наоборот. Таким образом, и сервер, и клиент могут понять любое полученное сообщение, даже не увидев предыдущих сообщений. Это отсутствие сохранения состояния обеспечивается за счёт использования ресурсов, а не команд. Они описывают любые объекты, документы или вещи, которые могут потребоваться для хранения или отправки в другие службы.
Эти ограничения помогают RESTful-приложениям достигать надёжности, быстрой производительности и расширяемости, как компонентам, которые могут быть управляемы, обновлены и повторно использованы, не затрагивая систему в целом даже во время её работы.
Теперь мы изучим, как на самом деле происходит взаимодействие между клиентом и сервером, когда мы внедряем RESTful-интерфейс.
Взаимодействие между клиентом и сервером
В архитектуре REST клиенты отправляют запросы на поиск или изменение ресурсов, а серверы отправляют ответы на эти запросы. Давайте рассмотрим стандартные способы направления запросов и ответов.
Отправка запросов
REST требует, чтобы клиент сделал запрос на сервер для получения или изменения данных на сервере. Запрос обычно состоит из:
Существует 4 основных метода НТТР, которые мы используем в запросах для взаимодействия с ресурсами в системе REST:
В заголовке запроса клиент отправляет тип контента, который он может получить с сервера. Это поле называется Accept. Оно обеспечивает, что сервер не посылает данные, которые не могут быть поняты или обработаны клиентом. Параметры типов контента — это типы MIME (или Multipurpose Internet Mail Extensions, о которых вы можете прочитать больше в MDN Web Docs).
Типы MIME, используемые для указания типов контента в поле Accept, состоят из типа и подтипа. Они разделены слэшем (/).
Другие типы и часто используемые подтипы:
Например, клиент, имеющий доступ к ресурсу с идентификатором 123 в ресурсе статей на сервере, может отправить запрос GET следующим образом:
Запросы должны содержать путь к ресурсу, на котором должна выполняться операция. В RESTful API пути должны быть разработаны так, чтобы помочь клиенту понять, что происходит. Обычно первая часть пути должна быть множественной формой ресурса. Это позволяет легко читать и понимать вложенные пути.
Пути должны содержать информацию, необходимую для определения местоположения ресурса с необходимой степенью конкретности. При ссылке на список или коллекцию ресурсов не всегда необходимо добавлять идентификатор. Например, запрос POST на путь somesite.com/persons не будет нуждаться в дополнительном идентификаторе, так как сервер генерирует идентификатор для нового объекта.
В тех случаях, когда сервер отправляет клиенту полезную нагрузку, он должен включать тип контента в заголовок ответа. Это поле заголовка контента предупреждает клиента о типе данных, которые он посылает в теле ответа. Эти типы контента являются типами MIME, точно так же, как они находятся в поле Accept заголовка запроса. Тип контента, который сервер возвращает обратно в ответе, должен быть одним из параметров, указанных клиентом в поле принятия запроса.
Например, клиент получает доступ к ресурсу с идентификатором 123 в разделе статей с этим запросом GET:
Сервер должен отправить обратно контент с заголовком ответа:
Это означает, что запрашиваемый контент возвращается в тело ответа с text/html — типом контента, который клиент будет в состоянии принять.
Коды ответов
Ответы от сервера содержат коды состояния для оповещения клиента об успехе операции. Как разработчику вам не нужно знать каждый код состояния (их много), но вы должны знать самые распространённые и то, как они используются.
Для каждого метода НТТР ожидаются коды статуса, которые сервер должен вернуть в случае успеха:
Если операция не работает, вернётся наиболее конкретный код состояния, соответствующий возникшей проблеме.
Предположим, у нас есть приложение, которое позволяет вам просматривать, создавать, редактировать и удалять клиентов и заказы для небольшого магазина одежды, размещённого на сайте fashionboutique.com. Мы можем создать НТТР API, который позволит клиенту выполнять следующие функции.
Если бы мы хотели увидеть всех клиентов, запрос выглядел бы так:
Возможный заголовок ответа будет выглядеть следующим образом:
Создание нового клиента путем размещения данных:
Затем сервер генерирует идентификатор этого объекта и возвращает его клиенту с таким заголовком:
Для просмотра одного клиента мы используем метод GET, указывая идентификатор этого клиента:
Возможный заголовок ответа будет выглядеть следующим образом:
Мы можем обновить этого клиента, вставив новые данные с помощью метода PUT:
Мы также можем УДАЛИТЬ этого клиента, указав его идентификатор:
Практика с REST
Давайте представим, что мы создаём сайт для сбора фотографий. Мы хотим сделать API, чтобы отслеживать пользователей, места проведения и фотографии этих мест. Этот сайт имеет index.html и style.css. Каждый пользователь имеет имя пользователя и пароль. Каждая фотография имеет место проведения и владельца (т.е. пользователя, который сделал фотографию). Каждое место имеет название и адрес. Можете ли вы разработать систему REST, которая будет учитывать:
Для начала опишите:
Архитектура REST
Введение
В русскоязычной части Интернета присутствует большое количество статей, посвященных веб-службам на основе SOAP и XML-RPC, но почему-то почти ничего нет про вполне заслуживающую внимания (но менее распространенную) архитектуру RESТ.
В данной статье описываются основы этой архитектуры, возможности и примеры её использования.
Что такое REST
REST (Representational state transfer) – это стиль архитектуры программного обеспечения для распределенных систем, таких как World Wide Web, который, как правило, используется для построения веб-служб. Термин REST был введен в 2000 году Роем Филдингом, одним из авторов HTTP-протокола. Системы, поддерживающие REST, называются RESTful-системами.
В общем случае REST является очень простым интерфейсом управления информацией без использования каких-то дополнительных внутренних прослоек. Каждая единица информации однозначно определяется глобальным идентификатором, таким как URL. Каждая URL в свою очередь имеет строго заданный формат.
А теперь тоже самое более наглядно:
Отсутствие дополнительных внутренних прослоек означает передачу данных в том же виде, что и сами данные. Т.е. мы не заворачиваем данные в XML, как это делает SOAP и XML-RPC, не используем AMF, как это делает Flash и т.д. Просто отдаем сами данные.
Каждая единица информации однозначно определяется URL – это значит, что URL по сути является первичным ключом для единицы данных. Т.е. например третья книга с книжной полки будет иметь вид /book/3, а 35 страница в этой книге — /book/3/page/35. Отсюда и получается строго заданный формат. Причем совершенно не имеет значения, в каком формате находятся данные по адресу /book/3/page/35 – это может быть и HTML, и отсканированная копия в виде jpeg-файла, и документ Microsoft Word.
Как происходит управление информацией сервиса – это целиком и полностью основывается на протоколе передачи данных. Наиболее распространенный протокол конечно же HTTP. Так вот, для HTTP действие над данными задается с помощью методов: GET (получить), PUT (добавить, заменить), POST (добавить, изменить, удалить), DELETE (удалить). Таким образом, действия CRUD (Create-Read-Updtae-Delete) могут выполняться как со всеми 4-мя методами, так и только с помощью GET и POST.
Вот как это будет выглядеть на примере:
GET /book/ — получить список всех книг
GET /book/3/ — получить книгу номер 3
PUT /book/ — добавить книгу (данные в теле запроса)
POST /book/3 – изменить книгу (данные в теле запроса)
DELETE /book/3 – удалить книгу
ВАЖНОЕ ДОПОЛНЕНИЕ: Существуют так называемые REST-Patterns, которые различаются связыванием HTTP-методов с тем, что они делают. В частности, разные паттерны по-разному рассматривают POST и PUT. Однако, PUT предназначен для создания, реплейса или апдейта, для POST это не определено (The POST operation is very generic and no specific meaning can be attached to it). Поэтому мой пример будет правильным и в таком виде, и в виде если поменять местами POST и PUT.
Вообще, POST может использоваться одновременно для всех действий изменения:
POST /book/ – добавить книгу (данные в теле запроса)
POST /book/3 – изменить книгу (данные в теле запроса)
POST /book/3 – удалить книгу (тело запроса пустое)
Это позволяет иногда обходить неприятные моменты, связанные с неприятием PUT и DELETE.
Использование REST для построения Web-сервисов.
Как известно, web-сервис – это приложение работающее в World Wide Web и доступ к которому предоставляется по HTTP-протоколу, а обмен информации идет с помощью формата XML. Следовательно, формат данных передаваемых в теле запроса будет всегда XML.
Для каждой единицы информации (info) определяется 5 действий. А именно:
GET /info/ (Index) – получает список всех объектов. Как правило, это упрощенный список, т.е. содержащий только поля идентификатора и названия объекта, без остальных данных.
GET /info/ (View) – получает полную информацию о объекте.
PUT /info/ или POST /info/ (Create) – создает новый объект. Данные передаются в теле запроса без применения кодирования, даже urlencode. В PHP тело запроса может быть получено таким способом:
POST /info/ или PUT /info/ (Edit) – изменяет данные с идентификатором
DELETE /info/ (Delete) – удаляет данные с идентификатором
Еще раз отмечу, что в нашем примере /info/ — может и базироваться на какой-то другой информации, что может быть (и должно) быть отражено в URL:
/data/4/otherdata/6/info/3/ … и тому подобное.
Какие можно сделать из этого выводы:
Как видно, в архитектура REST очень проста в плане использования. По виду пришедшего запроса сразу можно определить, что он делает, не разбираясь в форматах (в отличие от SOAP, XML-RPC). Данные передаются без применения дополнительных слоев, поэтому REST считается менее ресурсоемким, поскольку не надо парсить запрос чтоб понять что он должен сделать и не надо переводить данные из одного формата в другой.
Практическое применение.
Самое главное достоинство сервисов в том, что с ними работать может какая угодно система, будь то сайт, flash, программа и др. так как методы парсинга XML и выполнения запросов HTTP присутствуют почти везде.
Архитектура REST позволяет серьезно упростить эту задачу. Конечно в реальности, того что описано не достаточно, ведь нельзя кому угодно давать возможность изменять информацию, то есть нужна еще авторизация и аутентификация. Но это достаточно просто разрешается при помощи различного типа сессий или просто HTTP Authentication.
Введение в REST API — RESTful веб-сервисы
Эта статья начинает серию постов о разработке REST API:
Intro to RESTful Web Services
REST означает REpresentational State Transfer (Википедия: «передача состояния представления»). Это популярный архитектурный подход для создания API в современном мире.
Вы изучите:
Что такое REST?
REST расшифровывается как REpresentational State Transfer. Это был термин, первоначально введен Роем Филдингом (Roy Fielding), который также был одним из создателей протокола HTTP. Отличительной особенностью сервисов REST является то, что они позволяют наилучшим образом использовать протокол HTTP. Теперь давайте кратко рассмотрим HTTP.
Краткий обзор HTTP
Давайте сначала откроем браузер и зайдем на веб-страницу:
А затем щелкните на одной из страниц результатов:
Далее мы можем нажать на ссылку на странице, на которой мы оказались:
И перейти на другую страницу:
Вот как мы обычно просматриваем веб страницы.
Когда мы просматриваем страницы в Интернете, за кулисами происходит много вещей. Ниже приведено упрощенное представление о том, что происходит между браузером и серверами, работающими на посещаемых веб-сайтах:
Протокол HTTP
Когда вы вводите в браузере URL-адрес, например www.google.com, на сервер отправляется запрос на веб-сайт, идентифицированный URL-адресом.
Затем этот сервер формирует и выдает ответ. Важным является формат этих запросов и ответов. Эти форматы определяются протоколом HTTP — Hyper Text Transfer Protocol.
Когда вы набираете URL в браузере, он отправляет запрос GET на указанный сервер. Затем сервер отвечает HTTP-ответом, который содержит данные в формате HTML — Hyper Text Markup Language. Затем браузер получает этот HTML-код и отображает его на экране.
Допустим, вы заполняете форму, присутствующую на веб-странице, со списком элементов. В таком случае, когда вы нажимаете кнопку «Submit» (Отправить), HTTP-запрос POST отправляется на сервер.
HTTP и RESTful веб-сервисы
HTTP обеспечивает базовый уровень для создания веб-сервисов. Поэтому важно понимать HTTP. Вот несколько ключевых абстракций.
Ресурс
Ресурс — это ключевая абстракция, на которой концентрируется протокол HTTP. Ресурс — это все, что вы хотите показать внешнему миру через ваше приложение. Например, если мы пишем приложение для управления задачами, экземпляры ресурсов будут следующие:
URI ресурса
Когда вы разрабатываете RESTful сервисы, вы должны сосредоточить свое внимание на ресурсах приложения. Способ, которым мы идентифицируем ресурс для предоставления, состоит в том, чтобы назначить ему URI — универсальный идентификатор ресурса. Например:
REST и Ресурсы
Важно отметить, что с REST вам нужно думать о приложении с точки зрения ресурсов:
Определите, какие ресурсы вы хотите открыть для внешнего мира
Используйте глаголы, уже определенные протоколом HTTP, для выполнения операций с этими ресурсами.
Вот как обычно реализуется служба REST:
Компоненты HTTP
HTTP определяет следующую структуру запроса:
Методы HTTP-запроса
Метод, используемый в HTTP-запросе, указывает, какое действие вы хотите выполнить с этим запросом. Важные примеры:
Код статуса ответа HTTP
Код состояния всегда присутствует в ответе HTTP. Типичные примеры:
Резюме
В статье приведен на верхнем уровне обзор архитектурного стиля REST. Подчеркивается тот факт, что HTTP является основным строительным блоком REST сервисов. HTTP — это протокол, который используется для определения структуры запросов и ответов браузера. Мы видели, что HTTP имеет дело главным образом с ресурсами, доступными на веб-серверах. Ресурсы идентифицируются с помощью URI, а операции над этими ресурсами выполняются с использованием глаголов, определенных протоколом HTTP.
Наконец, мы рассмотрели, как службы REST наилучшим образом используют функции, предлагаемые HTTP, для предоставления ресурсов внешнему миру. REST не накладывает никаких ограничений на форматы представления ресурсов или на определение сервиса.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
REST (сокр. от англ. Representational State Transfer-«передача состояния представления»)— архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы. В определённых случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле[уточнить] компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является альтернативой RPC group: [Источник 1]
В сети Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно «GET» или «POST»; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса group: [Источник 2] group: [Источник 3]
Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».
В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют стандарты, такие как HTTP, URL, JSON и XML.
Содержание
История термина
Хотя данная концепция лежит в самой основе Всемирной паутины — термин «REST» был введён Роем Филдингом, одним из создателей протокола «HTTP», лишь в 2000 году. В своей диссертации «Архитектурные стили и дизайн сетевых программных архитектур» («Architectural Styles and the Design of Network-based Software Architectures»)group: [Источник 4]
Стиль «REST» развивался параллельно с «HTTP 1.1», разработанным в 1996—1999 годах, основываясь на существующем дизайне «HTTP 1.0», разработанном в 1996 году group: [Источник 5]
Свойства Архитектуры REST
Свойства архитектуры, которые зависят от ограничений, наложенных на REST-системы:
Рой Филдинг — один из главных авторов спецификации протокола HTTP, описывает влияние архитектуры REST на масштабируемость следующим образом:
Требования к архитектуре REST
Существует шесть обязательных ограничений для построения распределённых REST-приложений по Филдингу group: [Источник 6]
Выполнение этих ограничительных требований обязательно для REST-систем. Накладываемые ограничения определяют работу сервера в том, как он может обрабатывать и отвечать на запросы клиентов. Действуя в рамках этих ограничений, система приобретает такие желательные свойства как производительность, масштабируемость, простота, способность к изменениям, переносимость, отслеживаемость и надежность.
Если сервис-приложение нарушает любое из этих ограничительных условий, данную систему нельзя считать REST-системой.
Обязательными условиями-ограничениями являются:
Модель клиент-сервер
Первым ограничением применимым к нашей гибридной модели является приведение архитектуры к модели клиент-сервер, описанной в параграфе 3.4.1. Разграничение потребностей является принципом, лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса клиента от потребностей сервера, хранящего данные, повышает переносимость кода клиентского интерфейса на другие платформы, а упрощение серверной части улучшает масштабируемость. Наибольшее же влияние на всемирную паутину, пожалуй, имеет само разграничение, которое позволяет отдельным частям развиваться независимо друг от друга, поддерживая потребности в развитии интернета со стороны различных организаций.
Отсутствие состояния
Протокол взаимодействия между клиентом и сервером требует соблюдения следующего условия: в период между запросами клиента никакая информация о состоянии клиента на сервере не хранится. (Stateless protocol (англ.)русск.. Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Состояние сессии при этом сохраняется на стороне клиента. Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например в службу базы данных) для поддержания устойчивого состояния, например с целью, и на период установления аутентификации. Клиент инициирует отправку запросов, когда он готов (возникает необходимость) перейти в новое состояние.
Во время обработки клиентских запросов считается, что клиент находится в переходном состоянии. Каждое отдельное состояние приложения представлено связями, которые могут быть задействованы при следующем обращении клиента.
Кэширование
Как и во Всемирной паутине, клиенты а также промежуточные узлы могут выполнять кэширование ответов сервера. Ответы сервера в свою очередь должны иметь явное или неявное обозначение как кэшируемые или некэшируемые с целью предотвращения получения клиентами устаревших или неверных данных в ответ на последующие запросы. Правильное использование кэширования способно полностью или частично устранить некоторые клиент-серверные взаимодействия, ещё более повышая производительность и расширяемость системы.
Единообразие интерфейса
Наличие унифицированного интерфейса являются фундаментальным требованием дизайна REST-сервисов. Унифицированные интерфейсы позволяют каждому из сервисов развиваться независимо.
К унифицированным интерфейсам предъявляются следующие четыре ограничительных условия:
Манипуляция ресурсами через представление
Гипермедиа, как средство изменения состояния приложения
Код по требованию (необязательное ограничение)
REST может позволить расширить функциональность клиента за счёт загрузки кода с сервера в виде апплетов или сценариев. Филдинг утверждает, что дополнительное ограничение позволяет проектировать архитектуру, поддерживающую желаемую функциональность в общем случае, но возможно за исключением некоторых контекстов.
Преимущества
Филдинг указывал, что приложения, не соответствующие приведённым условиям, не могут называться REST-приложениями. Если же все условия соблюдены, то, по его мнению, приложение получит следующие преимущества:
Web-сервисы RESTful
Основы
REST определяет ряд архитектурных принципов проектирования Web-сервисов, ориентированных на системные ресурсы, включая способы обработки и передачи состояний ресурсов по HTTP разнообразными клиентскими приложениями, написанными на различных языках программирования. За последние несколько лет REST стала преобладающей моделью проектирования Web-сервисов. Фактически REST оказала настолько большое влияние на Web, что практически вытеснила дизайн интерфейса, основанный на SOAP и WSDL, из-за значительного более простого стиля проектирования.
Технология REST не привлекла большого внимания в 2000 году, когда Рой Филдинг (Roy Fielding) впервые представил ее в Калифорнийском университете в Ирвайне в своей диссертации «Архитектурные стили и дизайн сетевых архитектур программного обеспечения», где анализировался набор принципов архитектуры программного обеспечения, использующей Web в качестве платформы распределенных вычислений. Однако сегодня, по прошествии многих лет, возникли и продолжают развиваться многочисленные инфраструктуры для REST, которую, среди прочего, планируется интегрировать в стандарт Java™ 6 JSR-311.
Конкретная реализация Web-сервисов REST следует четырем базовым принципам проектирования:
Явное использование HTTP-методов
Одной из ключевых характеристик Web-сервиса RESTful является явное использование HTTP-методов согласно протоколу, определенному в RFC 2616. Например, HTTP GET определяется как метод генерирования данных, используемый клиентским приложением для извлечения ресурса, получения данных с Web-сервера или выполнения запроса в надежде на то, что Web-сервер найдет и возвратит набор соответствующих ресурсов.
REST предлагает разработчикам использовать HTTP-методы явно в соответствии с определением протокола. Этот основной принцип проектирования REST устанавливает однозначное соответствие между операциями create, read, update и delete (CRUD) и HTTP-методами. Согласно этому соответствию:
Недостатком проектирования многих Web API является использование HTTP-методов не по прямому назначению. Например, URI запроса в HTTP GET обычно определяет один конкретный ресурс, либо же строка запроса в URI запроса содержит ряд параметров, определяющих критерии поиска сервером набора соответствующих ресурсов. По крайней мере именно так описан метод GET в HTTP/1.1 RFC. Однако часто встречаются непривлекательные Web API, использующие HTTP GET для выполнения разного рода транзакций на сервере (например, для добавления записей в базу данных). В таких случаях URI запроса GET используется некорректно или, по крайней мере, не используется в REST-стиле (RESTfully). Если Web API использует GET для запуска удаленных процедур, запрос может выглядеть примерно так:
Это неудачный дизайн, поскольку вышеупомянутый Web-метод поддерживает меняющую состояние операцию посредством HTTP-запроса GET. Иначе говоря, HTTP-запрос GET имеет побочные эффекты. В случае успешного выполнения запроса в хранилище данных будет добавлен новый пользователь (в нашем примере – Robert). Проблема здесь в основном семантическая. Web-серверы предназначены для ответов на HTTP-запросы GET путем извлечения ресурсов согласно URI запроса (или критерию запроса) и возврата их или их представления в ответе, а не для добавления записи в базу данных. С точки зрения предполагаемого использования и с точки зрения HTTP/1.1-совместимых Web-серверов такое использование GET является ненадлежащим.
Кроме семантики еще одной проблемой является то, что для удаления, изменения или добавления записи в базу данных или для изменения каким-либо образом состояния на стороне сервера GET привлекает различные средства Web-кэширования (роботы) и поисковые механизмы, которые могут выполнять непреднамеренные изменения на сервере путем простого обхода ссылки. Простым способом решения этой общей проблемы является помещение имен и значений параметров URI запроса в XML-теги. Эти теги (XML-представление создаваемого объекта) можно отправить в теле HTTP-запроса POST, URI которого является родителем объекта (см.образец RESTful-запроса 1(До) и 2(После)). образец 1(До)
Это образец RESTful-запроса: HTTP-запрос POST используется корректно, а тело запроса содержит полезную нагрузку. На принимающей стороне в запрос может быть добавлен содержащийся в теле ресурс, подчиненный ресурсу, определенному в URI запроса; в данном случае новый ресурс должен добавляться как потомок /users. Такое отношение включения (containment) между новым логическим объектом и его родителем, указанное в запросе POST, аналогично отношению подчинения между файлом и родительским каталогом. Клиентское приложение устанавливает отношение между логическим объектом и его родителем и определяет URI нового объекта в запросе POST.
Затем клиентское приложение может получить представление ресурса, используя новый URI, указывающий, что по крайней мере логически ресурс расположен в /users (см. образец 3). образец 3. HTTP-запрос GET
Это правильное применение запроса GET, поскольку он служит только для извлечения данных. GET – это операция, которая должна быть свободной от побочных эффектов. Данное свойство известно также под названием идемпотентность.
Аналогичный рефакторинг Web-метода необходимо выполнить в тех ситуациях, когда HTTP-запрос GET поддерживает операцию update (см. образец 4). образец 4. Операция update в HTTP-запросе GET
Это запрос меняет атрибут (или свойство) name ресурса. Хотя для такой операции можно использовать строку запроса и в листинге 4 приведена самая простая из них, модель «строка запроса как сигнатура метода» не работает для более сложных операций. Поскольку нашей целью является явное использование HTTP-методов, по указанным выше причинам более RESTful-совместимым является подход, при котором для обновления ресурса применяется HTTP-запрос PUT вместо HTTP-запроса GET (см. образец 5). образец 5. HTTP-запрос PUT
Использование запроса PUT для замены исходного ресурса обеспечивает гораздо более прозрачный интерфейс, совместимый с принципами REST и с определением HTTP-методов. Запрос PUT в листинге 5 является явным в том смысле, что он указывает на обновляемый ресурс, определяя его в URI запроса, и передает новое представление ресурса от клиента на сервер в теле запроса PUT, вместо того чтобы передавать атрибуты ресурса в виде слабо связанного набора имен и значений параметров в URI запроса. Запрос в листинге 5 переименовывает ресурс с Robert на Bob и меняет его URI на /users/Bob. В Web-сервисе REST использование старого URI в последующих запросах ресурса приведет к возникновению стандартной ошибки 404 Not Found.
Общепринятым подходом, соответствующим рекомендациям REST по явному применению HTTP-методов, является использование в URI имен существительных вместо глаголов. В Web-сервисе RESTful глаголы POST, GET, PUT и DELETE уже определены протоколом. В идеале для реализации обобщенного интерфейса и явного вызова операций клиентскими приложениями Web-сервис не должен определять дополнительные команды или удаленные процедуры, например /adduser или /updateuser. Этот общий принцип применим также к телу HTTP-запроса, которое предназначено для передачи состояния ресурса, а не имени вызываемых удаленного метода или удаленной процедуры.
Несохранение состояния
Для удовлетворения постоянно растущих требований к производительности Web-сервисы REST должны быть масштабируемыми. Для формирования топологии сервисов, позволяющей при необходимости перенаправлять запросы с одного сервера на другой с целью уменьшения общего времени реакции на вызов Web-сервиса, обычно применяют кластеры серверов с возможностью распределения нагрузки и аварийного переключения на резерв, прокси-серверы и шлюзы. Использование промежуточных серверов для улучшения масштабируемости требует, чтобы клиенты Web-сервисов REST отправляли полные самодостаточные запросы, содержащие все необходимые для их выполнения данные, чтобы компоненты на промежуточных серверах могли перенаправлять, маршрутизировать и распределять нагрузку без локального сохранения состояния между запросами.
При обработке полного самодостаточного запроса серверу не нужно извлекать состояние или контекст приложения. Приложение (или клиент) Web-сервиса REST включает в HTTP-заголовки и в тело запроса все параметры, контекст и данные, необходимые серверному компоненту для генерирования ответа. В этом смысле несохранение состояния (statelessness) улучшает производительность Web-сервиса и упрощает дизайн и реализацию серверных компонентов, поскольку отсутствие состояния на сервере устраняет необходимость синхронизации сеансовых данных с внешним приложением.
На рисунке 1 показан сохраняющий состояние сервис, в котором приложение может запросить следующую страницу в многостраничном наборе результатов, полагая, что сервер хранит последовательность переходов приложения по этому набору результатов. В этой модели с сохранением состояния сервис наращивает и сохраняет переменную previousPage, чтобы быть в состоянии отвечать на запросы следующих страниц.
Подобные сохраняющие состояние сервисы получаются сложными. На платформе Java EE (Java Platform, Enterprise Edition) сохраняющие состояние сервисы требуют большого количества предварительных соглашений по эффективному хранению и синхронизации сеансовых данных в кластере Java EE-контейнеров. В средах такого типа разработчики сервлетов/страниц JSP (JavaServer Pages) и EJB-компонентов (Enterprise JavaBeans) сталкиваются с типичной проблемой поиска причин возникновения исключительной ситуации java.io.NotSerializableException при репликации сеанса. Независимо от источника (контейнер сервлетов при репликации HttpSession или EJB-контейнер при репликации сохраняющего состояние EJB-компонента) такая проблема может стоить разработчикам нескольких дней поисков в сложном графе объектов, определяющих состояние сервера, того единственного объекта, в котором реализуется Serializable. Кроме того, синхронизация сеансов увеличивает накладные расходы, что отрицательно сказывается на производительности сервера.
В противоположность этому, не сохраняющие состояния серверные компоненты более просты в проектировании, написании и распределении между серверами со сбалансированной нагрузкой. Не сохраняющий состояния сервис не только лучше работает, но и возлагает основную ответственность за сохранение состояния на клиентское приложение. В Web-сервисе RESTful сервер отвечает за генерирование ответов и за предоставление интерфейса, позволяющего клиентскому приложению самому хранить свое состояние. Например, при запросе многостраничного набора результатов клиентское приложение должно включать в запрос номер конкретной страницы, а не просто запрашивать следующую страницу (см. рисунок 2).
Не сохраняющий состояния Web-сервис генерирует ответ, содержащий ссылку на номер следующей страницы в наборе и позволяющий клиенту самостоятельно позаботиться о сохранении этого значения. В самом общем виде этот аспект модели Web-сервисов RESTful можно разделить на две сферы ответственности, объясняющие суть функционирования не сохраняющего состояние сервиса:
Сервер
Клиентское приложение
Такая совместная работа клиентского приложения и сервиса очень важна для отказа от сохранения состояния в Web-сервисах RESTful. Результатом ее является рост производительности за счет уменьшения трафика и минимизации состояния серверного приложения.
Отображение URI, аналогичных структуре каталогов
С точки зрения обращения к ресурсам из клиентского приложения предоставляемые URI определяют, насколько интуитивным будет Web-сервис REST и будет ли он использоваться так, как предполагал разработчик. Третья характеристика Web-сервиса RESTful полностью посвящена URI.
URI-адреса Web-сервиса REST должны быть интуитивно понятными. Рассматривайте URI как некий самодокументирующийся интерфейс, почти не требующий пояснения или обращения к разработчику для его понимания и для получения соответствующих ресурсов. Поэтому структура URI должна быть простой, предсказуемой и понятной.
Один из способов достичь такого уровня удобства использования – построение URI по аналогии со структурой каталогов. Такого рода URI являются иерархическими, исходящим из одного корневого пути, ветвления которого отображают основные функции сервиса. Согласно этому определению, URI – это не просто строка со слэшами в качестве разделителей, а скорее дерево с вышележащими и нижележащими ветвями, соединенными в узлах. Например, в сервисе обсуждений различных тем (от Java до бумаги) можно определить структурированный набор URI следующего вида:
Приведем некоторые дополнительные рекомендации, на которые следует обратить внимание при обдумывании структуры URI для Web-сервисов RESTful:
URI также должны быть статичными, чтобы при изменениях ресурсов или реализации сервиса ссылка оставалась той же. Это позволяет сохранить закладки. Также важно, чтобы взаимосвязи между ресурсами, закодированными в URI, оставались независимыми от способа указания местоположения ресурсов в хранилище.
Передача XML, JSON или обоих
Представление ресурса, как правило, отражает текущее состояние ресурса (и его атрибутов) на момент его запроса клиентским приложением. Представления ресурсов в этом смысле являются просто снимками состояния в конкретные моменты времени. Эти представления должны быть такими же простыми, как представление записи в базе данных, состоящее из отображения между именами столбцов и XML-тегами, где значения элементов в XML содержат значения строк. Если система имеет модель данных, то согласно этому определению представление ресурса является снимком состояния атрибутов одного из объектов модели данных системы. Это те объекты, которые будет обслуживать Web-сервис REST.
Последний набор ограничений, тесно связанный с дизайном Web-сервисов RESTful, относится к формату данных, которыми обмениваются приложение и сервис при работе в режиме запрос/ответ или в теле HTTP-запроса. Здесь особенно важны простота, читабельность и связанность.
Объекты модели данных обычно как-то связаны, и эти отношения между объектами (ресурсами) модели данных должны отражаться в способе их представления для передачи клиентскому приложению. В сервисе обсуждений пример представлений связанных ресурсов может включать в себя корневую тему обсуждения и ее атрибуты, а также встроенные ссылки на ответы, отправленные в эту тему.
XML-представление ветки обсуждения
Наконец, чтобы предоставить клиентским приложениям возможность запрашивать конкретный наиболее подходящий им тип содержимого, проектируйте сервис так, чтобы он использовал встроенный HTTP-заголовок Accept, значение которого является MIME-типом. Некоторые общеупотребительные MIME-типы, используемые RESTful-сервисами, перечислены в таблице 1.
Это позволит использовать сервис клиентским приложениям, написанным на разных языках и работающим на различных платформах и устройствах. Использование MIME-типов и HTTP-заголовка Accept представляет собой механизм согласования содержимого (content negotiation), позволяющий клиентским приложениям выбирать подходящий для них формат данных и минимизировать связность данных между сервисом и приложениями, его использующими.
Заключение
Технология REST – это способ проектирования Web-сервисов, менее зависимый от закрытого промежуточного программного обеспечения (например, сервер приложений), чем модели SOAP и WSDL. В некотором смысле REST, благодаря акценту на ранние интернет-стандарты URI и HTTP, является возвратом к Web до появления больших серверов приложений. Как вы увидели из рассмотрения принципов проектирования RESTful-интерфейса, XML поверх HTTP является мощным интерфейсом, позволяющим внутренним приложениям (например, пользовательским интерфейсам, основанным на технологии Ajax (Asynchronous JavaScript + XML)), легко подключаться и обращаться к ресурсам и потреблять их. Фактически именно хорошая совместимость Ajax и REST стала причиной сегодняшней популярности REST.
Представление системных ресурсов через RESTful API – это гибкий способ обеспечения различных приложений данными в стандартном формате. Это помогает выполнить требования к интеграции, имеющие решающее значение для создания систем, позволяющих легко комбинировать данные (машапов), а также для построения на основе набора базовых RESTful-сервисов более крупных конструкций.