Веб-сервисы RESTful
Перевод статьи RESTful Web Services: A Tutorial By M. Vaqqas
REST, означающий Representational State Transfer (передача состояния посредством представлений), и являющийся архитектурным стилем для сетевых гипермедиа-приложений, главным образом, использовался для построения Web-сервисов, легковесных, обслуживаемых и масштабируемых. Сервис построенный в стиле REST называется RESTful-сервисом. REST не зависит от какого-либо протокола, но почти каждый RESTful сервис использует HTTP как основной протокол. В этой статье я рассматриваю создание RESTful сервисов с HTTP.
Каждая система использует ресурсы (картинки, видео, веб-страницы, …). Назначением сервиса является обеспечение окна, через которое клиенты могут получить доступ к ресурсам. Архитекторы сервисов и разработчики хотят, чтобы с сервисом было легко работать, обслуживать, расширять и масштабировать. RESTful-сервисы должны обладать следующими свойствами и возможностями:
- Представления (Representations)
- Сообщения (Messages)
- URI
- Однородный интерфейс (Uniform interface)
- Не хранит состояния (Stateless)
- Ссылки между ресурсами
- Кэширование
Представления
Сервис RESTful сфокусирован на ресурсах и на том, как обеспечить доступ к этим ресурсам. Ресурс может состоять из других ресурсов. При проектировании системы следует определить ресурсы и как они связаны друг с другом.
Затем необходимо найти способ представления этих ресурсов в вашей системе. Вы можете использовать любой формат представления ресурсов, т.к. REST не накладывает ограничений на формат представления.
Например, вы можете использовать JSON или XML. Если строить Web-сервисы, которые будут использоваться Web-страницами для AJAX-вызовов, JSON является подходящим выбором. Например, ресурс "Person" может быть представлен так:
Листинг 1: JSON-представление ресурса
1 { 2 "ID": "1", 3 "Name": "M Vaqqas", 4 "Email": "m.vaqqas@gmail.com", 5 "Country": "India" 6 }
Хорошее представление должно обладать следующими качествами:
- И клиент, и сервер должны знать этот формат представления.
- Представление должно полностью представлять ресурс. Удовлетворение этого требования может привести к разбиению ресурса на дочерние ресурсы и, соответственно, к более мелким представлениям.
- Представление должно быть способно связывать ресурсы друг с другом. Это может быть сделано размещением URI или уникального ID связанного ресурса в представлении.
Сообщения
Клиент и сервис общаются друг с другом посредством сообщений. Клиент посылает запрос на сервер (request), а сервер отвечает (response). Помимо собственно данных, эти сообщения также содержат метаданные о сообщении. Важно иметь базовые знания о форматах запросов и ответов HTTP 1.1 для проектирования RESTful Web-сервисов.
НТТР запрос (HTTP Request)
HTTP запрос имеет следующий формат:
<Глагол> | <URI> | <Версия HTTP> |
<Заголовок запроса> | ||
<Тело запроса> |
Глагол - один из HTTP методов типа GET, PUT, POST, DELETE, OPTIONS, и.т.д.
URI - URI ресурса, на котором будет выполнена операция
Версия HTTP - версия HTTP, обычно "HTTP v1.1" .
Заголовок запроса - содержит метаданные в виде коллекции пар ключ-значение заголовков и их значений. Эти установки содержат информацию о сообщении и его отправителе, например: типе клиента, поддерживаемых клиентом форматах, типе формата тела сообщения, настроек кэша для ответа, и много другой информации.
Тело запроса - фактически контент сообщения. Именно здесь находится представление ресурса RESTful сервиса.
Нет никаких тегов или разметки, которые бы отмечали начало или конец раздела в HTML сообщении.
Листинг 2. Пример сообщения для запроса POST, предназначенного для вставки нового ресурса Person.
1 POST http://MyService/Person/ HTTP/1.1 2 Host: MyService 3 Content-Type: text/xml; charset=utf-8 4 Content-Length: 123 5 <?xml version="1.0" encoding="utf-8"?> 6 <Person> 7 <ID>1</ID> 8 <Name>M Vaqqas</Name> 9 <Email>m.vaqqas@gmail.com</Email> 10 <Country>India</Country> 11 </Person>
Как видно, за командой POST следует URI и версия HTTP. Этот запрос также содержит некоторые заголовки. Host – это адрес сервера. Content-Type говорит о типе контента в теле сообщения. Content-Length – длина данных в теле сообщения. Content-Length может использоваться для проверки, что всё тело сообщения было получено. Обратите внимание на отсутствие начального и конечного тегов в этом сообщении.
Листинг 3. Реальный запрос GET, который был создан моим браузером, когда я попытался обратиться к спецификации HTTP 1.1 на сайте w3.org:
1 GET http://www.w3.org/Protocols/rfc2616/rfc2616.html HTTP/1.1 2 Host: www.w3.org 3 Accept: text/html,application/xhtml+xml,application/xml; … 4 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 … 5 Accept-Encoding: gzip,deflate,sdch 6 Accept-Language: en-US,en;q=0.8,hi;q=0.6
Здесь нет тела сообщения. Заголовок Accept сообщает серверу о различных форматах представления, которые поддерживает клиент. Сервер, если он поддерживает более одного формата представления, может выбрать формат представления ответа во время исполнения запроса в зависимости от значения заголовка Accept. User-Agent содержит информацию о типе клиента, который сделал запрос. Accept-Encoding/Language сообщает о кодировке и языке, которые поддерживает клиент.
НТТР ответ (HTTP Response)
Формат HTTP ответа:
<Версия HTTP> | <Код ответа> |
<Заголовок ответа> | |
<Тело ответа> |
Сервер возвращает код ответа (response code), который содержит статус запроса. Этот код ответа обычно представлен 3-цифровым кодом состояния HTTP.
Заголовок ответа содержит метаданные и установки сообщения-ответа.
Тело ответа содержит представление, если запрос был успешным.
Листинг ниже показывает реальный ответ, который я получил на запрос, приведенный в листнге 3:
Листинг 5. Ответ на GET запрос.
1 HTTP/1.1 200 OK 2 Date: Sat, 23 Aug 2014 18:31:04 GMT 3 Server: Apache/2 4 Last-Modified: Wed, 01 Sep 2004 13:24:52 GMT 5 Accept-Ranges: bytes 6 Content-Length: 32859 7 Cache-Control: max-age=21600, must-revalidate 8 Expires: Sun, 24 Aug 2014 00:31:04 GMT 9 Content-Type: text/html; charset=iso-8859-1 10 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 11 <html xmlns='http://www.w3.org/1999/xhtml'> 12 <head><title>Hypertext Transfer Protocol -- HTTP/1.1</title></head> 13 <body> 14 ...
Код ответа 200 OK означает, что всё прошло хорошо, и тело сообщение сообщения ответа содержит валидное представление ресурса, который я запросил. В данном случае представлением является HTML документ, что объявлено заголовком Content-Type в заголовке ответа. Заголовки в сообщении объясняют себя сами, но я обсужу некоторые из них позже в этой статье. Существует много других атрибутов. Вы можете захватить и проверить такие запросы и ответы НТТР используя бесплатный инструмент Fiddler.