Не прошло и пяти лет, как в HTTP утвердили глагол QUERY. Вот теперь заживем!
Краткая история:
• сложные запросы плохо ложатся в query-параметры
• 10 лет назад пытались пофиксить, разрешив слать тело в GET, но никто это особо не поддержал
• сейчас решили вынести этот кейс в отдельный глагол
Как это будет выглядеть:
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json
select=surname,givenname,email&limit=10&match=%22email=*@example.*%22
HTTP/1.1 200 OK
Content-Type: application/json
Content-Location: /contacts/stored-results/17
Location: /contacts/stored-queries/42
Last-Modified: Sat, 25 Aug 2012 23:34:45 GMT
Date: Sun, 17 Nov 2024, 16:10:24 GMT
[
{ "surname": "Smith",
"givenname": "John",
"email": "smith@example.org" },
{ "surname": "Jones",
"givenname": "Sally",
"email": "sally.jones@example.com" },
{ "surname": "Dubois",
"givenname": "Camille",
"email": "camille.dubois@example.net" }
]
Чем же QUERY отличается от привычной реализации через POST?
— Он ИДЕМПОТЕНТНЫЙ
Ну да, а мы-то сейчас при чтении постом полбазы апдейтим
— Его можно кэшировать!!!
Вы предлагаете кэшировать на уровне тела, мы давно так делаем в GraphQL и прочих RPC
— Результат работы QUERY можно повторно получить с помощью GET
Получается, мы создаем некий вспомогательный ресурс с помощью QUERY. Т.е. это не только чтение?
Обновление актуально для тех, кто все еще стремиться делать "каноничное REST API", остальные давно оставили в покое несвежий труп стюардессы. Справедливости ради, даже для нормальных рестов первого уровня было бы удобно выделить логику из POST в другой глагол для единообразия, но вангую, что судьба этого обновления будет примерно такой же, как у GET-body и стандарта на описание ошибок в HTTP.