REST полезно включать параметры в тело запроса GET, а не в URI?

Question

У меня сложная схема, которая требует сложных вызовов API.Для многих поисков ресурсов пользователь может указать несколько параметров для фильтрации результатов.Включение всех этих параметров в URI кажется сложным и сложным для разработчиков переднего плана, поэтому я решил поместить параметры в тело запроса в виде JSON.К сожалению, это не совсем подходит для веб-интерфейса, который я использую (Django-Rest Framework).Является ли это RESTful, или я делаю ошибку?

В качестве дополнительного вопроса, если я должен поместить параметры в URI, как бы я представлял сложные фрагменты данных, такие как списки строк иотношения между частями данных?

Answer 1

Из того, что я читал о RESTful, вы можете использовать только GET, POST, PUT, PATCH и DELETE.

GET и DELETEне ожидается включение тела.Как упомянуто @VoiceOfUnreason, это происходит главным образом потому, что кеши могут быть проблемы с обработкой тела вдоль GET.При этом, если ваши результаты никогда не кэшируются, это не должно быть проблемой вообще.(т. е. вернуть Cache: no-cache и другие подобные HTTP-заголовки с вашего сервера.)

Нет реального соглашения о строке запроса и списках поддержки или JSON и подобных.Если вы хотите сохранить GET, вы можете использовать закодированную строку JSON.С этим проблем не возникает, за исключением длины URL.

http://www.example.com/?query=<encoded-json>

( в кодировке просто означает, что вы должны правильно экранировать специальные символы URI, чем JavaScript *Функция 1021 * делает.)

Длина URL должна быть меньше 1 КБ, чтобы быть на 100% безопасной.Вы можете провести некоторые исследования, я думаю, что браузер с самым строгим ограничением составляет около 2 тыс.

1026 * Если вы хотите использовать запрос большего размера, то вам следует вернуть свои запросы к использованию POST ине GET.Тогда буфер в этой ситуации нормальный, и ответ не будет кэшироваться.

---

Использование в реальном мире (но Не оправдание )

Если вызагляните в Elasticsearch , вы увидите, что все их запросы принимают JSON.Вы можете отправить DSL-запрос, используя GET или POST.Любой из них принимает JSON в своем теле.

Они предлагают POST, потому что большинство браузеров не примут присоединение тела к методу GET.Так что GET запросы не будут работать вообще из браузера.

---

Пример массивов в строках запроса

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

path/?var[1]=123&var[2]=456&var[3]=789

В этом случае эти языки преобразуют значение в массив.$_GET['var'][1] тогда вернет 123.

Это не соглашение, а расширение этой конкретной среды.

Answer 2

Это RESTful или я ошибаюсь?

Мне кажется, что вы делаете ошибку.Полномочия в этом случае: RFC 7231

Полезная нагрузка в сообщении запроса GET не имеет определенной семантики;отправка тела полезной нагрузки по запросу GET может привести к тому, что некоторые существующие реализации отклонят запрос.

Моя интерпретация такова: кэширование является важной частью Интернета;для того, чтобы кэширование работало так, как того ожидают люди, необходимо, чтобы совместимые кэши могли управлять этим телом сообщения как частью ключа.

HTTP-метод, который может лучше удовлетворить ваши потребности, - SEARCH .

Метод SEARCH играет роль транспортного механизма для запроса и набора результатов.Он не определяет семантику запроса.Тип запроса определяет семантику.

SEARCH - безопасный метод;он не имеет никакого значения, кроме выполнения запроса и возврата результата запроса.

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

как бы я представлял сложные фрагменты данных, такие как списки строк, и взаимосвязи между фрагментами данных?

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

Вы можетеНапример, рассмотрите возможность использования одной из кодировок Base64 , определенных в RFC 4648

.