Не прошло и 10 лет (нет, прощло, кстати), как стандартизация HTTP Query метода почти закончета! Ну да ладно, зато все наконец то двигается.
▶️ В чем проблема? В дизайне API. Чтобы сделать запрос к апи, сейчас используют несколько вариантов. Например,
GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
Host: example.org
Сложность с этим в том, что прааметры запроса в URL могут иметь разный допустимый размер, ограничивающися в разных системах через который проходит запрос. Приходится кодировать данные для передачи в URL. В логах видны, что прегружает логи. Неудобно. А засунуть в body запрос нельзя, потому что нету такой принятой семантики у body для GET, не поддержвиается.
Для решения этих проблем часто используют:
POST /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
q=foo&limit=10&sort=-published
Но проблема идемпотентности такого запроса - чисто серверная. Можно ли повторять запрос при сетевых сбоях? Не ясно. И кеширование тут ограничено. И, самое главное, ломается семантика. Мы хотим просто сделать запрос (не меняя объект), а метод используем, который подразумевает изменение ресурса! Оч нелогично, и это договоренность на уровне апи системы, окружающая инфраструктура (кеши, прокси, браузеры, файерволы, ...) всего этог оне понимают.
Предложено решение, берущее лучшее из обоих подходов:
QUERY /feed
Content-Type: application/x-www-form-urlencoded
q=foo&limit=10&sort=-published
Как у POST параметры в body. Как GET имеет семантику безопасного запроса на чтение. Идемпотентный, кешируемый. Сервер может вернуть Location или Content-Location, чтобы потом клиент мог обращаться к результату через обычный GET.
В общем, одни плюсы! Осталось чтобы поддержка дошла до всех систем, но со стандартом оно проще пойдет!
🔗 Почитать: https://datatracker.ietf.org/doc/rfc10008/
▶️ Зачем пишу? Для агентов любое АПИ важно, оно им удобнее и понятнее. Развитие стандартов для апи, получается, профильная тема.
(ц) хорошие говсти, в принципе!
@deksden_notes