Модель зрелости Ричардсона
Шаги по направлению к REST
(Перевод статьи
Модель (разработанная Леонардом Ричардсоном) разделяет основные элементы REST-подхода на 3 шага. Вот эти шаги: ресурсы, http-глаголы и элементы управления гипермедиа.
Недавно я читал черновой вариант книги
Для объяснения конкретных свойств систем, разработанных в стиле веб, авторы используют модель 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-сообщение в некоторую обертку.