В REST API принято для получения использовать GET-методы. Но что если требуется передать сложные параметры (к примеру, когда есть списки в запросе)? GET запрещает тело. Отойти от правил и использовать POST вместо GET?
Здравствуйте, Shmj, Вы писали:
S>В REST API принято для получения использовать GET-методы. Но что если требуется передать сложные параметры (к примеру, когда есть списки в запросе)? GET запрещает тело. Отойти от правил и использовать POST вместо GET?
Как вариант сериализавать нужные параметры в json и передать как параметр в строке запроса.
Здравствуйте, Shmj, Вы писали:
S>В REST API принято для получения использовать GET-методы. Но что если требуется передать сложные параметры (к примеру, когда есть списки в запросе)? GET запрещает тело. Отойти от правил и использовать POST вместо GET?
Лучше бы на конкретном примере.
Сложно сходу придумать задачу, чтобы была необходимость пихать в GET полноценные сложные объекты.
А для простых вещей вот такие варианты вполне нормально выглядят.
// Returns list of entities with given ids
GET \api\entities\1;2;10;15
// Returns part of the map enclosed by given area
GET \api\map\moscow?area=(10,10);(20,25);(30,41);(30,41);(0;12)
Здравствуйте, Shmj, Вы писали:
S>В REST API принято для получения использовать GET-методы. Но что если требуется передать сложные параметры (к примеру, когда есть списки в запросе)? GET запрещает тело. Отойти от правил и использовать POST вместо GET?
GET умеет работать со списками, есть лишь заковык с конкретным синтаксисом (три варианта, но не все браузеры/фреймворки умеют все три — надо проверять)
Здравствуйте, Shmj, Вы писали:
S>В REST API принято для получения использовать GET-методы. Но что если требуется передать сложные параметры (к примеру, когда есть списки в запросе)? GET запрещает тело.
Не запрещает, просто не рекомендует.
S> Отойти от правил и использовать POST вместо GET?
Глупо. POST неидемпотентен, автоматически лишаешься возможности кеширования. И да, списки в query string вполне передаются.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Глупо. POST неидемпотентен, автоматически лишаешься возможности кеширования. И да, списки в query string вполне передаются.
Тут же не так тупо все. Нужна поддержка Swagger, к примеру, и тут начинаются проблемы...
Здравствуйте, Shmj, Вы писали:
НС>>Глупо. POST неидемпотентен, автоматически лишаешься возможности кеширования. И да, списки в query string вполне передаются. S>Тут же не так тупо все.
А как у тебя там все нетупо?
S> Нужна поддержка Swagger, к примеру, и тут начинаются проблемы...
Здравствуйте, Shmj, Вы писали:
S>В REST API принято для получения использовать GET-методы. Но что если требуется передать сложные параметры (к примеру, когда есть списки в запросе)? GET запрещает тело. Отойти от правил и использовать POST вместо GET?
принято кому как удобней, скажем google analytics использует post
а яндекс в аналогичных случаях get, изобретая мануал с описанием строки запроса
и сколько таких "pure" rest сервисов, столько "мануалов"
Das Reich der Freiheit beginnt da, wo die Arbeit aufhört. (c) Karl Marx
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> Отойти от правил и использовать POST вместо GET?
НС>Глупо. POST неидемпотентен, автоматически лишаешься возможности кеширования. И да, списки в query string вполне передаются.
А так ли нужна идемпотентность, если нужно просто получить данные? Не, я понимаю — неправославно, типа, но это ж не религиозный догмат, тебя вебапи-инквизиция не потащит на костёр за злонамеренное использование POST вместо GET?
НС>>Глупо. POST неидемпотентен, автоматически лишаешься возможности кеширования. И да, списки в query string вполне передаются.
J>А так ли нужна идемпотентность, если нужно просто получить данные? Не, я понимаю — неправославно, типа, но это ж не религиозный догмат, тебя вебапи-инквизиция не потащит на костёр за злонамеренное использование POST вместо GET?
А если нужны строго актуальные данные, то может и фиг с ним, с кэшированием.
Здравствуйте, yenik, Вы писали:
J>>А так ли нужна идемпотентность, если нужно просто получить данные? Не, я понимаю — неправославно, типа, но это ж не религиозный догмат, тебя вебапи-инквизиция не потащит на костёр за злонамеренное использование POST вместо GET? Y>А если нужны строго актуальные данные, то может и фиг с ним, с кэшированием.
Да и вообще, возможность самостоятельно наступить на грабли никто не отменял.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Глупо. POST неидемпотентен, автоматически лишаешься возможности кеширования. И да, списки в query string вполне передаются.
Идемпотентность — это свойство реализации, а не способа RPC, коим любой вызов HTTP разумеется является.
Кеширование же полностью управляется хидерами со стороны сервера и "автоматически" никто такой возможности не лишается.
Здравствуйте, Shmj, Вы писали:
S>В REST API принято для получения использовать GET-методы. Но что если требуется передать сложные параметры (к примеру, когда есть списки в запросе)? GET запрещает тело. Отойти от правил и использовать POST вместо GET?
да, например поиск со сложными параметрами в json запускается именно как POST, в том числе у широкоизвестных сервисов типа elastic search, кошерная чистота GET запросов существует только в учебниках, на практике делается так, как практично и удобно
Здравствуйте, Mystic Artifact, Вы писали: MA> Кеширование же полностью управляется хидерами со стороны сервера и "автоматически" никто такой возможности не лишается.
Никакими хидерами кэширование POST включить не выйдет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>В REST API принято для получения использовать GET-методы. Но что если требуется передать сложные параметры (к примеру, когда есть списки в запросе)? GET запрещает тело. Отойти от правил и использовать POST вместо GET?
Я в заголовки запроса пихаю, при условии что они не особо важны и могут быть проигнорированы.