REST «механизмы коммуникации ресурсов» и «на лету» улучшение знаний клиента о них - PullRequest
Новая
       20

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

2 голосов
/ 02 февраля 2010

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

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Интересующая меня концепция заключается в этой цитате:

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

В частности, что такое знание «механизмов коммуникации с ресурсами», как эти знания описаны в документации / спецификациях и реализованы в реализации? Тогда, как лучше всего улучшить эти знания «на лету»? Я думаю, что понимаю вопрос «знание клиентом типов медиа».

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

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

Уточнение:

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

1 Ответ

2 голосов
/ 02 февраля 2010

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

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

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

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

Улучшается на лету

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

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

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

...