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

Question

Указывает ли рекомендация 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", которые может иметь клиентская программабесполезно для.

Answer 1

В собственных словах Роя Филдинга (4-й пункт в статье):

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

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

---

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

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

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

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

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

---

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

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

---

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

Я не вижу, какие строки запроса имеют отношение к отслеживанию состояния.Смысл принципа 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 очень слабое, я отвечаю, главным образом, чтобы разобраться в голове и получить обратную связь.Конечно, есть лучший ответ.

Answer 6

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

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