Управление сложными данными с помощью GET

Question

Мне часто сложно управлять сложными запросами GET без отправки тела JSON. Параметры URL просто не будут обрезаны. Если мне удастся найти работу с параметрами URL-адресов, тогда она обычно добавляет больше сложности и путаницы.

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

{ page: { batch: 10, current: 1 } 
, sort: { _id: -1 } 
, project: {history: 0, attach: 0} 
, filter: { status: "new"} 
} 

Это простой запрос без массивов. Массивы просто делают это еще более проблематичным.

Итак, мои вопросы: как вы управляете сложными запросами GET без тела JSON? Что я делаю/думаю неправильно? Почему мы не можем иметь тело с GET?

Да, я, вероятно, могу отправить этот запрос с использованием параметров URL, но это делает жизнь намного сложнее, особенно когда вам нужно отправить фильтры, пейджинг, а что нет ...

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

Answer 1

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

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

Нет абсолютно ничего, что мешает вам отправлять полезную нагрузку по запросу GET. В RFC 7231 говорится, что полезная нагрузка GET не имеет определенной семантики, поэтому вам будет удобно включать ее, пока вы ее документируете. Поскольку нет стандартной семантики, вам необходимо определить единый интерфейс для вашей экосистемы API. Однако большая проблема заключается в том, что, хотя ваше приложение может иметь дело с полезной нагрузкой GET просто отлично, многие реализации HTTP между вами и вашим клиентом могут и не быть. Возможно, клиент или ваш HTTP-сервер игнорирует его, или кэш-сервер не будет кэшировать его и т. Д.

С учетом этого POST также является методом, который можно использовать для обхода поврежденных реализаций. Например, многие общедоступные API имеют заголовок X-HTTP-Method-Override, позволяющий вам выполнить запрос PUT или PATCH с использованием метода POST, указав фактический метод, который будет использоваться в заголовке, в случае, если некоторая реализация между ними не понимает PUT и PATCH.

Итак, на вашем месте я бы просто использовал POST и документировал, как я его использую, как вы уже это делали; или я бы принял полезную нагрузку на запросы GET и разрешил клиентам использовать POST, чтобы сделать запрос с полезной нагрузкой в ​​случае нарушения какой-либо реализации, установив для этого заголовок переопределения.

Answer 2

Я думаю, что эти две ссылки могли бы дать вам несколько советов:

• How to desing RESTful advanced search/filter
• https://templth.wordpress.com/2014/12/15/designing-a-web-api/

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

Вы можете посмотреть на то, как OData управляет этим (особенно параметры запроса $filter, $count, $orderby, $skip и $top). См. Эту ссылку для получения более подробной информации: http://docs.oasis-open.org/odata/odata/v4.0/csprd01/part2-url-conventions/odata-v4.0-csprd01-part2-url-conventions.html#_Toc355091894.

Надеется, что это помогает вам, Тьерри