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

Окончание статьи. Читать с начала.

Уровень 3 – элементы управления гипермедиа

Финальный уровень вводит то, что вы часто слышите в связи с уродливым акронимом HATEOAS (гипертекст как двигатель состояния приложения). Он отвечает на вопрос о том, какие действия следует предпринять, чтобы записаться на прием, получив список доступных времен приема.

Рис. Уровень 3 добавляет элементы управления гипермедиа

Начнем с того же исходного GET, который мы посылали на уровне 2

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

Теперь ответ содержит новый элемент

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

<openSlotList>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450">
     <link rel = "/linkrels/slot/book" 
           uri = "/slots/1234"/>
  </slot>
  <slot id = "5678" doctor = "mjones" start = "1600" end = "1650">
     <link rel = "/linkrels/slot/book" 
           uri = "/slots/5678"/>
  </slot>
</openSlotList>

Каждый временной интервал теперь содержит элемент ссылки с URI, который сообщает нам, как записаться на прием.

Назначение элементов управления гипермедиа - сообщать нам, какое следующее действие мы должны выполнить, и URI ресурса, с которым мы должны взаимодействовать, чтобы это сделать. Вместо знания того, куда отправить наш запрос записи на прием, элементы управления гипермедиа в ответе говорят нам о том, как это сделать.

Опять скопирую POST из уровня 2

POST /slots/1234 HTTP/1.1
[различные заголовки]

<appointmentRequest>
  <patient id = "jsmith"/>
</appointmentRequest>

Ответ же содержит множество элементов управления гипермедиа для различных вещей, которые можно сделать следом.

HTTP/1.1 201 Created
Location: http://royalhope.nhs.uk/slots/1234/appointment
[разные заголовки]

<appointment>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
  <link rel = "/linkrels/appointment/cancel"
        uri = "/slots/1234/appointment"/>
  <link rel = "/linkrels/appointment/addTest"
        uri = "/slots/1234/appointment/tests"/>
  <link rel = "self"
        uri = "/slots/1234/appointment"/>
  <link rel = "/linkrels/appointment/changeTime"
        uri = "/doctors/mjones/slots?date=20100104@status=open"/>
  <link rel = "/linkrels/appointment/updateContactInfo"
        uri = "/patients/jsmith/contactInfo"/>
  <link rel = "/linkrels/help"
        uri = "/help/appointment"/>
</appointment>

Очевидным преимуществом элементов управления гипермедиа является то, что они позволяют серверу изменять схему своих URI без нарушений на клиентах. Теперь когда клиенты ищут ссылку URI «addTest» (добавить проверку), команда сервера может манипулировать всеми URI, кроме начальных точек входа.

Другое преимущество состоит в том, что оно позволяет разработчикам клиента исследовать протокол. Ссылки дают разработчикам клиента подсказку о дальнейших действиях. При этом не дается вся информация: оба элемента управления «latest» и «cancel» указывают на один и тот же URI – они должны догадаться, что один – это GET, а другой – DELETE. Но, по крайней мере, это дает им направление, в котором следует искать больше информации на подобный URI в документации протокола.

Это еще и позволяет команде разработчиков сервера объявлять новые возможности, размещая новые ссылки в ответах. Если разработчики клиента замечают незнакомые ссылки, эти ссылки могут послужить для дальнейших исследований.

Не существует абсолютного стандарта на то, как представлять элементы управления гипермедиа. То, что я делал здесь, - это использование текущих рекомендаций авторов книги REST in Practice, которые заключаются в следовании спецификациям ATOM (RFC 4287). Я использую элемент <link> с атрибутом uri для целевого URI, а атрибут rel для описания вида связи. Широко известная связь (такая как self для ссылки на сам элемент) является пустой, любая специфичная для сервера связь является полностью квалифицированным URI. ATOM утверждает, что определения для хорошо известных отношений связи находятся в документе Registry of Link Relations. Написанное здесь согласуется со сделанным в ATOM, который представляется лидером на уровне 3 следования стилю REST.

Смысл уровней

Следует отметить, что модель Ричардсона, будучи хорошим способом мыслить об элементах REST, не является определением уровней самого REST. Рой Филдинг ясно дал понять, что уровень 3 модели Ричардсона является предварительным условием REST. Подобно многим терминам в программировании, REST обладает множеством определений, но, поскольку Рой Филдинг ввел этот термин, его определение имеет больший вес, чем остальные.

Я считаю полезным в модели Ричардсона то, что она обеспечивает хороший пошаговый способ к пониманию базовых концепций, лежащих в основе стиля REST. В этом плане я вижу его в качестве инструмента, который помогает нам освоить концепции, а не служить механизмом оценки некоторого рода. Я считаю, что мы еще не имеем достаточно примеров, чтобы быть уверенными в том, что restful подход является правильным путем для интеграции систем. Я думаю, что это привлекательный подход, который я бы рекомендовал в большинстве ситуаций.

В разговоре со мной Ян Робинсон подчеркнул, что, когда Леонард Ричардсон впервые представил свою модель, он нашел привлекательным её связь с традиционными методами проектирования.

Уровень 1 решает проблему сложности методом «разделяй и властвуй», разбивая конечную точку большого сервиса на множество ресурсов.
Уровень 2 вводит стандартный набор глаголов так, что мы можем обрабатывать подобные ситуации одинаковым образом, устраняя несущественные различия.
Уровень 3 вносит способность к обнаружению, предоставляя способ сделать протокол более самодокументируемым.

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

страницы 1 2 3