fkthatЭто некошерно. Возврат результатов поиска должен быть через GET. Это такой бест практис - запрос чего-то не изменяющий состояние сервера должен быть GET, а изменения на сервере это POST/PUT/DELETE.

То, что GET должен быть идемпотентным -- да, однозначно
POST может использоваться как GET в случаях, когда запрос представляет собой сложный объект, и чисто технически GET использовать невозможно.

Кошерность тут не при чём, дас ист реальность )

carrotik.. на другом форуме мне сказали, что POST для получения данных (не для создания сущности на сервере) мешает использовать кнопку "назад" в браузере

я имел в виду про API.

с точки зрения браузера всё несколько иначе, да и семантика другая.

fkthatНе, ну, конечно, в иной ситуации не то что некошерное съешь, но и свинины ломоть заточишь. Но, делая поиск через пост мы, например, теряем возможность "вперед-назад", или возможность сохранить результаты поиска в закладках и т.п. Ну и плюс POST с отображением его результата это сам по себе трефной подход, т.к. кошером считается паттерн "Post/Redirect/Get"

вперёд-назад не теряем, если это SPA :)

но вот прям упарываться и пытаться сделать GET не нужно, как этого хочет ТС
P/R/G конечно известный паттерн, но он немного про другое, его задача решать проблему повторной отправки формы, в том числе по F5

fkthathVosttвперёд-назад не теряем, если это SPA :)

Ну, где SPA, там и REST, а с т.з. REST поиск через POST это уже вообще по ту сторону зла :)

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

чистота GET это про уникальный адрес ресурса и обращение к ресурсу.
параметры запроса в query string уже пинают этой концепции по яйцам.

так что пофигу что у вас там будет для получения данных: GET или POST.
абсолютно монопенисуально :)


fkthatПри поиске с этим тоже будет проблема. По Ф5 страшного ничего не случится, но будет анноящее предупреждение о повторной отправке. "Убивать тебя не станут, но тоже ничего хорошего" (с)

веб не идеален )

fkthatПочему же. Очень даже по REST. Есть ресурс (path часть URL, то что до "?"). У ресурса может быть множество разных представлений. А query string - это как раз опции представления этого одного и того же ресурса.

У query string есть ряд ограничений. На длину строки в первую очередь, во вторую на передачу структуры, а не плоский набор параметров -- придётся извращаться. В третью, ограниченный набор символов, придётся эскейпить, что сильно влияет на длину строки.

В итоге, я не понимаю, чего ради еб****ь, чтобы влезть в ограничения, если можно использовать POST и передавать нормальные структуры данных с поддержкой UTF-8.


fkthatРазжую пример с поиском. Запрос на поиск мы трактуем как ресурс. Есть коллекция этих ресурсов с URL, допустим, "/api/search", отдельный ресурс запроса поиска будет иметь URL "/api/search/{id}". Ресурс поиска имеет два представления (representation) - параметры поиска, например в JSON и список с результатами поиска. Теперь клиент отправляет POST на /api/search передавая параметры поиска (первое представление), а POST по URL коллекции это как раз создание ресурса. Сервер сохраняет этот ресурс (запрос) в каком-нибудь storage, клиенту возвращается ID созданного ресурса. Допустим "4269". Теперь клиент делает запрос GET по URL этого ресурса /api/search/4269 и в ответ получает второе представление этого ресурса (список с результатами поиска). Все как раз предельно по REST.

REST не накладывает ограничения на использование POST для read-only получения данных.
Видимо вы никогда не имели никаких дел со сложной клиентской фильтрацией, поэтому у вас рассуждения ограничиваются исключительно придуманной себе REST-религией и собственным опытом.

Как заметил Дмитрий выше, хороший пример GraphQL, в котором запрос к данным это сложный объект, который передаётся в JSON.


fkthatДа мир вообще не идеален. Порой по необходимости такого наговнокодишь, что в страшном сне не привидится. Но в данном случае речь ведь не идет о выборе "сделать трефно, но зато за один день или делать кошерно, но целый год". Я сам такую шляпу однажды делал, и если уже есть вся логика самого поиска, то дел тут от силы на пару-тройку человекочасов.

Никаких минусов в использовании POST для запроса данных нет. Кроме упорото религиозных конечно.
И никто не говорил, что семантика это плохо. Нет, но нужно смотреть на мир не через розовые очки, и понимать, что нужно решать задачи, а не обтёсывать кирпичики до идеально ровных граней.

fkthatВзглянул мельком - показалось, что какая-то шляпа. Чо уж тогда до конца не идти, и не разрешить передачу sql запроса прямо в http. Кстати, в MS SQL такая тема была еще лет 10 назад, потом потом, видать таки поняли, что за херь на самом деле придумали, и фичу эту нах выпилили.

Ну и зачем выдумывать всякую ересь? Ничего никто не выпиливал, откуда такие больные фантазии берутся-то?

https://www.nuget.org/packages/Microsoft.AspNetCore.OData