REST "механизмы коммуникации ресурсов" и "на лету" улучшение знаний клиентов о них

Я пытаюсь примириться с REST, как это определено Роем Филдингом. Недавно я пытался обдумать:

Концепция, которая меня интересует, приведена в этой цитате:

В частности, что такое знание "механизмов обмена ресурсами", как это знание описано в документации/спецификациях и реализовано в реализации? Затем, как лучше улучшить это знание "на лету"? По-моему, я понимаю, что обращается к "клиентским знаниям типов медиа".

У меня есть некоторые догадки (PUT, GET и т.д.), но я бы оценил любые предложения, примеры или указатели на API RESTful, которые явно адресуют проблемы в этой цитате. Если это поможет, я думаю об этих проблемах в контексте HTTP + JSON, я считаю, что REST не ограничивается HTTP + *.

API Sun Cloud ранее был процитирован как хороший дизайн RESTful, я не мог понять, где и как он решает эти конкретные проблемы - может быть, случай отсутствия дерева для деревьев?

Что меня озадачивает, если PUT, GET и т.д. являются ли эти механизмы, это говорит о том, что клиент знает, что применять к конкретным гиперссылкам в пределах некоторого < media-type > , и это кажется хрупким и может предлагать гипертекстовую ссылку (непосредственно) к ресурсам.

Ответы

Ответ 1

Механизмы связи ресурсов

Посредством "механизмов связи ресурсов", я считаю, что Roy ссылается на HTTP-запросы и HTTP-глаголы. Он просто говорит об этом, не указывая HTTP, потому что REST не зависит от HTTP. Я бы сказал, что для 99,99% всех сервисов REST механизм обмена ресурсами документирован в RFC2616.

API Sun Cloud отвечает этим требованиям, потому что все, что клиент должен понимать для использования API, - это как выполнять HTTP-запросы и семантику возвращаемых типов медиа. Например, если клиент не понимает, что содержится в документе типа application/vnd.com.sun.cloud.Cloud+json, тогда он не сможет использовать API.

Это контрастирует с такими услугами, как OData и SData, которые не определяют новые типы носителей, но предполагают, что клиент знает, как извлекать данные домена из фида Atom, и ожидает, что клиент будет создавать URL-адреса на основе набора правил, определяющих пространство URI. Это прямо противоречит рекомендациям Роя.

Улучшено на лету

Честно говоря, я могу только догадываться о том, что Рой намекает сюда. Я мог бы представить сценарий, в котором загруженный javascript мог бы использоваться для создания URL-адреса на основе ввода пользователем. Это может помешать серверу явно создать URL-адрес для каждого элемента в списке.

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

Загруженный код также может использоваться для динамического изменения глагола по ссылке. Если вы хотите отредактировать ресурс, он может сделать GET, если вы хотите удалить этот ресурс, выполните DELETE. Это позволит представлению содержать только одну ссылку, но может выполнять несколько операций.