Модель зрелости Ричардсона

Шаги по направлению к REST

(Перевод статьи Richardson Maturity Model By Martin Fowler)

Модель (разработанная Леонардом Ричардсоном) разделяет основные элементы REST-подхода на 3 шага. Вот эти шаги: ресурсы, http-глаголы и элементы управления гипермедиа.

Недавно я читал черновой вариант книги “Rest на практике“, над которой работает пара моих коллег. Они ставят себе цель объяснить, как использовать веб-сервисы Restful для решения многих проблем интеграции, с которыми сталкиваются предприятия. В книге исходят из того, что web фактически представляет собой неограниченно масштабируемую распределенную систему, которая реально работает, и мы можем заимствовать отсюда идеи более простого построения интегрированных систем.

Для объяснения конкретных свойств систем, разработанных в стиле веб, авторы используют модель restful maturity, которая была разработана Леонардом Ричардсоном и озвучена им на конференции QCon. Эта модель представляет собой замечательный способ осмысления использования данной техники, поэтому я решил дать ей своё объяснение. (Приведенные примеры протоколов преследуют лишь иллюстративную цель. Я не думаю, что стоит их кодировать и тестировать, поскольку возможны ошибки в деталях.)

Уровень 0

Начальной точкой модели является использование HTTP в качестве транспортной системы для удаленных взаимодействий, но без использования каких-либо механизмов веб. Существенной особенностью здесь является использование НТТР как механизма туннелирования для вашего собственного механизма удаленного взаимодействия, обычно основанного на вызове удаленных процедур.


Рис. Пример взаимодействия на уровне 0

Предположим, я хочу записаться на прием к моему врачу. Моей программе записи на приём для начала нужно знать свободное время приема врача на данный день, поэтому она делает запрос к системе записи на прием поликлиники, чтобы получить эту информацию. В сценарии уровня 0 поликлиника будет предоставлять конечную точку сервиса по некоторому URI. Затем я посылаю в эту точку приема документ, содержащий детали моего запроса.

POST /appointmentService HTTP/1.1
[другие заголовки]

<openSlotRequest date = "2010-01-04" doctor = "mjones"/>

После чего сервер вернет документ, дающий мне такую информацию

HTTP/1.1 200 OK
[различные заголовки]

<openSlotList>
  <slot start = "1400" end = "1450">
    <doctor id = "mjones"/>
  </slot>
  <slot start = "1600" end = "1650">
    <doctor id = "mjones"/>
  </slot>
</openSlotList>

Для примера я здесь использую XML, однако контент может быть представлен в виде JSON, YAML, пары ключ-значение или в каком-нибудь пользовательском формате.

Следующий шаг – это запись на прием, который я опять могу сделать, отправив документ в конечную точку сервиса.

POST /appointmentService HTTP/1.1
[другие заголовки]

<appointmentRequest>
  <slot doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointmentRequest>

Если все нормально, я получу ответ, сообщающий мне, что запись на прием сделана.

HTTP/1.1 200 OK
[различные заголовки]

<appointment>
  <slot doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointment>

Если возникает проблема, например, кто-то раньше меня успел записаться на это время, то я получу некоторое сообщение об ошибке в теле ответа.

HTTP/1.1 200 OK
[различные заголовки]

<appointmentRequestFailure>
  <slot doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
  <reason>Время приема занято
</appointmentRequestFailure>

Пока это система точно в стиле RPC (вызов удаленных процедур). Она просто реализует передачу туда и обратно плоских старых XML (POX). Если вы используете SOAP или XML-RPC, это будет примерно тот же механизм с тем лишь отличием, что вы заворачиваете XML-сообщение в некоторую обертку.

страницы 1 2 3