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 решения.