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

fkthatPOST по URL коллекции это как раз создание ресурса

И ещё, у нас в одном решении, в час бывает больше ста тысяч запросов с поиском и фильтрацией, клиентов со всей страны. За такое решение, как вы предложили, разработчиков бы избили.

Дмитрий МухhVosttЗа такое решение, как вы предложили, разработчиков бы избили.
Да ладно тебе.
Вполне рабочее решение, когда данные предварительно подготавливаются, кладутся например в Redis, или Couchbase, и отдаются по некому идентификатору, ключу, токену.

Ну так это совершенно другая задача, например, запрос отчёта. Данные либо долго готовятся, либо многократно затем используются.

Для кеширования не обязательно сохранять запрос под ID, можно сам запрос кешировать, как делают СУБД.

Дмитрий МухНу почему же только отчёта.
Вполне себе решение для REST API, где клиенту нужен набор данных, соответсвующих указанному фильтру,
чтобы потом как-то крутить эти данные у себя какое-то время.

Я так и сказал, многократно используется. Если говорить про UX, то ещё можно сохранить под каким-нибудь именем, шарить, использовать за основу... ой, погодите-ка, так же реализовано в TFS :))

fkthatОДата как-то, похоже, тоже не взлетел особо.

Друг, намеренно игнорируешь ссылку, которую я привёл выше? OData живёт и здравствует, развивается, активно используется. Если нет истеричного хайпа, как у GraphQL, это ещё не значит, что "не взлетело".

fkthatЯ чота живой-здоровый пока что. А за P/R/G тоже избивают? Насколько сильно - с увечьями?

P/R/G решает другую задачу совсем, а не способ "обмануть" идеалы REST, то вообще из другой оперы, про классическое взаимодействие форм, отправляемых с браузера :)

fkthathVostt,

Кстати, а ничего, что OData для получения данных как раз следует "идеалам REST" и везде GET использует?

Это неправда.

http://docs.oasis-open.org/odata/odata/v4.01/csprd05/part2-url-conventions/odata-v4.01-csprd05-part2-url-conventions.html#sec_PassingQueryOptionsintheRequestBody

fkthatЖивет и здравствует тем, что раз в год новый релиз выходит? Ну так jQuery тоже так живет и здравствует - кому только он сейчас уже нужен.

jQuery до сих пор используется очень активно, там, где не используются другие фреймворки.
Для не-SPA приложений, jQuery всё также актуален, релизы не выходят часто, так как в нём всё уже есть, в основном, вводится поддержка нативного АПИ.

fkthatКак мне сохранить результат поиска в закладках?

Это другая задача. Тем более, АПИ поиска может измениться, поэтому твой сохранённый GET с кучей параметров, просто может не заработать. Т.е. имеем очередную проблему вместо решения.

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

fkthatДа уж, видел я как он используется. Тысячестрочная лапша, где вперемешку свалены данные, обработчики событий и код обновления DOM. Особенно жесть, когда это все еще написано на адской функциональщине с дюжиной вложенных коллбеков и анонимных функций и замыканий а каждое выражение. Я некоторое время назад ушел с работы, где очень хорошо платили, потому что понял, что с той кучей гамна ужаса, которую к тому моменту написали там на jQuery уже ничего сделать просто нельзя.

Проблема не в jQuery. Собственно, при отсутствии jQuery код, о котором вы говорите, был бы ещё раза в 2-3 страшнее. Ну и не рассчитан он как фреймворк для создания полноценных клиентских веб-приложений.


fkthatjQuery был очень крут для своего времени, почти что как C для своего (когда UI ограничивался консолью).

И почему же для текущего времени он вдруг перестал быть таким же крутым? Что такого изменилось качественно за это время? В браузерах появилось АПИ, которое реализует многое из того, что раньше было в jQuery, но он не перестал быть уродским и неудобным для использования. ПРоблема кроссбраузерности всё ещё существует.

fkthatСейчас же, даже как личный опыт показывает, аппетиты заказчика в части вебовского Rich UI всегда растут как снежный ком, и при малейшем намеке на это надо сразу же перепрыгивать на какой-нибудь MVC-подобный фреймворк, иначе впереди ждет глубокая жопа.

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

fkthathVosttДля обычного контентного сайта jQuery с ограниченным интерактивом до сих пор один из лучших вариантов.

Да. Но за текущий год уже два раза сталкивался с проектами (нехилого размера), где на jQuery пытались писать достаточно навернутые именно веб-приложения, а вовсе не контентный сайт. Оба раза это был треш, угар, и содомия.

Я треш, угар и содомию наблюдал и на Backbone, Ember, на React, и на Angular (особенно на нём), и даж на Vue.

И 90% это обычный говнокодинг, и где-то +/- 10% из-за проблем конкретных инструментов.

В тоже время писали довольно сложное приложение с огромны количеством интерактива на jQuery. И норм, до сих пор используется, как b2b, так и b2c решения.