Веб-сервисы RESTful

Перевод статьи RESTful Web Services: A Tutorial By M. Vaqqas

REST, означающий Representational State Transfer (передача состояния посредством представлений), и являющийся архитектурным стилем для сетевых гипермедиа-приложений, главным образом, использовался для построения Web-сервисов, легковесных, обслуживаемых и масштабируемых. Сервис построенный в стиле REST называется RESTful-сервисом. REST не зависит от какого-либо протокола, но почти каждый RESTful сервис использует HTTP как основной протокол. В этой статье я рассматриваю создание RESTful сервисов с HTTP.

Каждая система использует ресурсы (картинки, видео, веб-страницы, …). Назначением сервиса является обеспечение окна, через которое клиенты могут получить доступ к ресурсам. Архитекторы сервисов и разработчики хотят, чтобы с сервисом было легко работать, обслуживать, расширять и масштабировать. RESTful-сервисы должны обладать следующими свойствами и возможностями:

Представления

Сервис 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	}

Хорошее представление должно обладать следующими качествами:

  1. И клиент, и сервер должны знать этот формат представления.
  2. Представление должно полностью представлять ресурс. Удовлетворение этого требования может привести к разбиению ресурса на дочерние ресурсы и, соответственно, к более мелким представлениям.
  3. Представление должно быть способно связывать ресурсы друг с другом. Это может быть сделано размещением 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.

страницы 1 2 3