HATEOAS подразумевает, что строки запроса не являются RESTful?

Является ли рекомендация HATEOAS (гипермедиа как двигатель состояния приложения) подразумевать, что строки запроса не являются RESTful?

Изменить: было предложено ниже, что строки запросов могут не иметь большого отношения к состоянию, и поэтому вопрос вызывает недоумение. Я бы предположил, что для URI не имеет смысла иметь строку запроса, если клиент не заполняет аргументы. Если клиент заполняет аргументы, он фальсифицирует предоставленный сервером URI, и мне интересно, нарушает ли он принцип RESTful.

Изменить 2: Я понимаю, что строка запроса кажется безобидной, если клиент рассматривает ее как непрозрачную (и строка запроса может быть наследственной и, следовательно, удобной). Однако в одном из ответов ниже Рой Филдинг цитируется, что URI следует считать прозрачным. Если это прозрачно, я считаю, что фальсификация поощряется и, по-видимому, разбавляет принцип HATEOAS. Разве такое разбавление по-прежнему согласуется с HATEOAS? Это ставит вопрос о том, призывает ли REST к жесткому соединению, которое похоже на URI-здание.

Обновление. В этом учебнике REST http://rest.elkstein.org/ предлагается, что URI-здание плохо проектируется и не является RESTful, Он также повторяет то, что было сказано @zoul в принятом ответе.

Например, запрос "список продуктов" может вернуть идентификатор для каждого продукта, а в спецификации указано, что вы должны использовать http://www.acme.com/product/PRODUCT_ID для получить дополнительную информацию. Это плохой дизайн. Скорее, ответ должен включать фактический URL-адрес с каждым элементом: http://www.acme.com/product/001263 и т.д. Да, это означает, что результат больше. Но это также означает, что вы можете легко перенаправить клиентов на новые URL-адреса по мере необходимости

Если человек смотрит на этот список и не хочет, что он/она может видеть, могут быть "предыдущие 10 элементов" и кнопка "следующие 10 пунктов", однако, если нет человека, а скорее клиентская программа, этот аспект REST кажется немного странным из-за всего "http://www, что клиентская программа может не использовать.

Ответ 1

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

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

<photos>
    <photo url="http://somewhere/photo?id=1"/>
    <photo url="http://somewhere/photo?id=2"/>
</photos>

Вместо этого вы можете использовать /photo/id/xx путь, но это не так. Эти URL-адреса можно использовать даже без изменения клиента. Что касается вашего второго пункта:

Если клиент заполняет аргументы то это фальсифицирует серверный URI, и мне интересно, если это нарушает принцип RESTful.

Думаю, это суть вашего вопроса. И я не думаю, что вам нужно рассматривать URL как непрозрачные идентификаторы, см. эту цитату от Роя Филдинга:

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

Ответ 2

В Roy Fielding собственные слова (4-я маркерная точка в статье):

API REST не должен определять фиксированные имена ресурсов или иерархии (очевидное соединение клиента и сервера). Серверы должны иметь свободу контролировать свое пространство имен. Вместо этого разрешать серверам указывать клиентам о том, как создавать соответствующие URI, например, в форматах HTML и шаблонах URI,, определяя эти инструкции в типах медиа и отношениях ссылок.

Другими словами, до тех пор, пока клиенты не получают кусочки, которые им нужны для создания URI в внеполосной информации, HATEAOS не нарушается.

Обратите внимание, что шаблоны URI могут использоваться в URI без строк запроса:

http://example.com/dictionary/{term}

Итак, вопрос в том, является ли RESTful разрешать клиенту создавать URL-адреса, чем RESTful использовать строки запроса.

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

Он также позволяет клиенту искать словарь при соблюдении HATEAOS, что было бы невозможно без внутриполосных инструкций. Я вполне уверен, что Рой Филдинг не продвигает Web без какой-либо функции поиска...

О вашем третьем комментарии, я думаю, что Рой Филдинг поощряет дизайнеров API иметь "прозрачные" URI в качестве дополнительной функции поверх HATEAOS. Я не интерпретирую его цитату в ответе zoul как утверждение о том, что клиенты будут использовать "здравый смысл" для навигации по API с явными URI. Они все равно будут использовать внутриполосные инструкции (например, формы и шаблоны URI). Но это не означает, что прозрачные URI не лучше, чем темные, неожиданные, непрозрачные URI.

Фактически, прозрачные URI предоставляют добавленную ценность API (отладка - один из вариантов использования, я могу думать о том, где прозрачные URI являются неоценимыми).

Для получения дополнительной информации о шаблонах URI, вы можете посмотреть RFC6570.

Ответ 3

Я считаю, что сам REST ничего не говорит о непрозрачности или прозрачности URI, но приложение REST не должно зависеть от клиента для создания URI, о котором сервер еще не сказал. Для этого сервер имеет множество способов: например, коллекция, которая может включать ссылки на ее членов, или HTML-форму с помощью метода GET, очевидно, приведет к созданию URI с параметрами, создаваемыми на стороне клиента и извлеченными, или есть, по крайней мере, несколько предлагаемых стандартов для шаблонов URI. Важной вещью для REST является то, что описание допустимого URI должно каким-то образом определяться сервером в ответах, которые он дает клиентам, а не в какой-либо внеполосной документации API

Прозрачность URI - это хорошая вещь, так же, как прозрачность в любом месте - это хорошая вещь - она продвигает и разрешает новые и незапланированные использования ресурсов за пределами того, что первоначально предполагал дизайнер, - но (по крайней мере, в моем понимании) хорошие URI не требуется описывать интерфейс как RESTful

Ответ 4

Я не вижу, какие строки запросов связаны с отслеживанием состояния. Суть принципа HATEOAS заключается в том, чтобы воздерживаться от отслеживания состояния на клиенте, от "обмана" и перехода к "известным" URL-адресам для данных. Являются ли эти URL-адреса строками запроса или нет, мне не подходит.

О. Может быть, вас интересует что-то вроде поисковых URL, где определенная часть URL-адреса должна изменяться в соответствии с критериями поиска? Поскольку такие URL-адреса, казалось бы, должны были быть известны заранее, таким образом представляя внеполосную информацию, которую мы стремимся устранить с помощью REST? Я думаю, что это можно решить с помощью шаблонов URL. Пример:

client -> server
    GET /items
server -> client
    /* …whatever, an item index… */
    <search by="color">http://somewhere/items/colored/{#color_id}</search>

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

Ответ 5

Нет HATEOAS не означает, что строки запроса не являются RESTful. На самом деле может быть и точная противоположность.

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

Вот еще один пример сохранения состояния клиента в URL: http://yuml.me/diagram/scruffy/class/[Company]< > -1 > [Location], [Location] + → [Point ]

Ответ 6

Чтобы следить за тем, что сказал Даррел, вам не нужно изменять URL-адрес для включения второго URL-адреса.

Для проверки подлинности на основе файлов cookie вы можете вернуть форму входа в тело ответа 401 с пустым действием формы и использовать уникальные имена полей, которые могут быть отправлены и обработаны каждым ресурсом. Таким образом, вы полностью исключаете необходимость перенаправления. Если у вас не может быть запросов на вход в систему ресурса, вы можете сделать пункт действия формы 401 ресурсу входа в систему и поместить URL-адрес переадресации в скрытое поле. В любом случае, вы избегаете уродливого URL-in-a-URL, и первый способ избегает необходимости как для входа в систему RPC, так и для перенаправления, сохраняя все взаимодействие, сосредоточенное на ресурсе.