⚪️ HTTP QUERY Не прошло и 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