Введение в концепции REST

На практике REST предоставляет руководство по внедрению интерфейсов веб-приложений в Интернете. Обычно говорят, что веб-приложение построено в стиле REST или нет. REST часто ассоциируется (или внедряется) с HTTP, но может быть реализован и с другими технологиями. REST не зависит от платформы и языка.

Рой Филдинг, изобретатель REST, говорит, что REST стремится достичь следующего:

• Универсальность интерфейсов. Все веб-приложения должны реализовывать свои интерфейсы одинаково. Делясь тем же соглашением, другие приложения знают, как называть ваши, и вы знаете, как называть их. Минимальная кривая обучения для каждого нового приложения.
• Независимое развертывание компонентов. После того, как приложение и его интерфейсы REST были реализованы и развернуты, необходимо иметь возможность внедрять или повторно внедрять и развертывать любые интерфейсы REST без необходимости переписывать или изменять существующие.
• Инкапсуляция устаревших систем. Существующие приложения, которые не реализованы в стиле REST, могут быть обернуты интерфейсами REST, что делает их приложениями, подобными REST.
• Посреднические компоненты для уменьшения задержки взаимодействия. Например, для обработки трафика принято распределять запросы пользователей / клиентов по нескольким физическим серверам (что не следует путать с логическими серверами). Это прозрачно для пользователей. Поскольку REST использует интерфейсы, реализация или добавление дополнительных многоуровневых компонентов, таких как физические серверы, для обработки пика клиентских запросов, очень проста.
• Подчеркивая масштабируемость взаимодействия компонентов — это дополняет предыдущий пункт.
• Обеспечить безопасность — обмен информацией через Интернет может быть рискованным. Хакеры могут использовать это, чтобы крутить систему. Принципы REST устраняют многие из этих рисков.

Концепции

• Ресурс . Логическим ресурсом является любая концепция (автомобиль, собака, пользователь, счет-фактура…), к которой можно обращаться и ссылаться с использованием глобального идентификатора. Как правило, каждый ресурс доступен с URI при реализации REST через HTTP (например: http://www.mysite.com/invoice/34657).
• Сервер — логический сервер, на котором расположены ресурсы, а также любые соответствующие функции хранения данных. Такие серверы не имеют дело с интерфейсами конечного пользователя (GUI).
• Клиент — логические клиенты делают запросы к логическим серверам для выполнения операций над их ресурсами. Например, клиент может запросить состояние ресурса, создать ресурс, обновить ресурс, удалить ресурс и т. Д. Клиенты не обладают ресурсами или соответствующими функциями хранения данных. Однако они имеют дело с интерфейсами конечного пользователя (GUI).
• Запрос и ответы — взаимодействие между клиентом и серверами организовано с помощью запросов от клиента к серверу и ответов на запросы от сервера обратно к клиенту. Запросы могут содержать представления ресурса.
• Представление — Представление — это документ, представляющий текущее состояние ресурса. Это также может быть новый желаемый статус, когда клиент, например, делает запрос на обновление ресурса.

принципы

Вот некоторые принципы, применимые в REST-подобных приложениях:

• Состояние ресурса остается внутренним для сервера, а не для клиента — клиент может запросить его или обновить его с помощью запросов, сделанных на сервер.
• Между запросами не сохраняется контекст клиента на сервере . Сервер не должен хранить статус клиента. В противном случае это нарушит масштабируемость REST при достижении пары миллионов пользователей. Помните, что запросы могут быть распределены на несколько физических серверов, что может вызвать проблемы с потреблением физических ресурсов.
• Клиентские запросы содержат всю информацию для его обслуживания — независимо от того, какой запрос отправляется клиентом на сервер, он должен быть достаточно полным, чтобы сервер его обработал.
• Сеансовые состояния хранятся на стороне клиента. При необходимости любая информация о состоянии связи между логическим сервером и логическим клиентом должна храниться на стороне клиента.
• Может существовать несколько представлений ресурса . Выбранный формат, используемый для представления состояния ресурса в запросах и ответах, является бесплатным (XML, JSON…). Можно использовать несколько форматов.
• Ответы явно указывают на их кешируемость. Когда сервер возвращает ответ на запрос, информация, которую он содержит, может кэшироваться или не кэшироваться клиентом. Если нет, клиент должен сделать новые запросы, например, для получения последнего статуса ресурса.
• Код по запросу — это дополнительная функция в REST. Клиенты могут получить некоторый дополнительный код с сервера, чтобы обогатить свои функциональные возможности. Примером является Javascript.

Что касается состояний сеансов, реализация системы выхода из системы (т. Е. Аутентификации) между физическим сервером и физическим клиентом требует сохранения информации о сеансе на стороне сервера. В противном случае, если он был сохранен на стороне клиента, он может быть взломан на стороне клиента.

Существует общее согласие, что любой «ресурс», необходимый для реализации аутентификации между клиентом и сервером, считается вне области действия для REST. Эти ресурсы аутентификации не должны следовать принципам REST (подробнее см. Здесь ).

ОТДЫХ через HTTP

При реализации REST через HTTP логическим клиентом REST обычно является веб-браузер, а логическим сервером REST является веб-сервер. REST API (или служба) должны управляться гипертекстом .

Об идентификаторах ресурсов:

• Предпочтение отдается существительным, а не глаголам, чтобы указать тип ресурса (кошка, собака, машина …).
• Уникальный идентификатор ресурса — это URI , например: http://www.mysite.com/invoice/34657.
• Группа ресурсов также может быть доступна с помощью URI, например: http://www.mysite.com/user/7723/invoices.

Также считается хорошей практикой использовать URI в представлениях ресурсов, когда ресурс ссылается на другой ресурс. Например, в документе XML, представляющем ресурс:

Для выполнения операций над ресурсами используется простой HTTP для вызовов между компьютерами. HTTP знает несколько типов вызовов: PUT, GET, POST, DELETE, HEAD, CONNECT, PATCH, TRACE и OPTIONS.

Однако REST использует только четыре: PUT, GET, POST и DELETE.

• GET — клиенты могут запрашивать состояние ресурса, отправляя HTTP-запрос GET на сервер, используя URI ресурса. REST требует, чтобы эта операция не создавала побочных эффектов для состояния ресурса (нулевого).
• PUT — Создает новый ресурс. Поскольку клиент не знает следующий номер счета, URI может быть следующим: http://www.mysite.com/invoice. Если ресурс уже создан, он не воссоздается. Другими словами, REST PUT на http://www.mysite.com/invoice/841 (например) является (и должен быть) идемпотентом. Счет 841 не должен создаваться несколько раз, если клиенты вызывают этот PUT несколько раз.
• POST — REST требует, чтобы запросы клиента POST обновляли соответствующий ресурс информацией, предоставленной клиентом, или создавали этот ресурс, если он не существует. Эта операция не идемпотентна.
• DELETE — эта операция удаляет ресурс навсегда. Это идемпотент.

REM: реализация
http://www.mysite.com/invoice/add URI не считается REST-совместимой практикой.

Формат (JSON, XML…), используемый для возврата представлений ресурсов, задается в типе носителя ответа сервера (Multipurpose Internet Mail Extensions — MIME).

Для решения проблем успеха или ошибок HTTP REST рекомендует использовать один из кодов состояния HTTP .

Дополнительное чтение

• http://www.infoq.com/articles/rest-introduction

Ссылка: Введение в REST Concepts от нашего партнера JCG Джерома Версринга в блоге технических заметок .