В июне вышел новый метод REST - QUERY.

В июне вышел новый метод REST - QUERY. Он пришел на замену методу SEARCH. Ещё в 2008 году мир разработчиков вздохнул с облегчением: вышел RFC с методом SEARCH. Наконец-то поиск узаконен! Но при ближайшем рассмотрении выяснилось: Метод пришёл из мира WebDAV - это протокол для совместного редактирования документов, а не для веб-API. Он требовал отправлять XML-запросы в специфическом формате DAV:searchrequest. Никакого JSON. Этот метод не был идемпотентным. В WebDAV SEARCH мог запускать долгие фоновые задачи, которые меняли состояние сервера (например, перестраивали индексы). Прокси-серверы и CDN не могли кешировать SEARCH-ответы. Отчаявшись, разработчики пустились во все тяжкие. Родились несколько паттернов: GET с телом запроса Передача фильтров в POST Некоторые блюстители чистоты REST предлагали элегантное решение: создать ресурс поиска

POST /search-jobs с телом запроса: получаем jobId

GET /search-jobs/{jobId}?page=2 для получения результатов

Новый язык запросов: GraphQL В 2015 году группа энтузиастов попыталась изменить стандарт, но наткнулась на отчаянное сопротивление сообщества WebDAV. Поэтому началась работа над новым стандартом

Филдинг, автор REST и один из отцов HTTP, выступил с жёсткой критикой нового стандарта

Кеширование должно происходить только по URI

Но QUERY без кеширования тела запроса не решает исходную проблему, поэтому в стандарте его оставили

Даже когда согласились, что кеширование QUERY нужно, возник следующий вопрос

Как именно строить кеш из тела запроса?

Тело запроса - это большой JSON. Если я отправлю {"a":1, "b":2} и {"b":2, "a":1} - это одинаковые запросы или разные? В итоге вопрос остался на усмотрение разработчиков Ещё один важный вопрос:

В каком формате передавать поисковой запрос?

Одни участники считали, что нужен стандартный язык запросов (например, SQL-подобный). Другие настаивали, что это выходит за рамки HTTP. В итоге и этот вопрос оставили на усмотрение разработчика @maximbelovmentor