Які основні відмінності між методами запиту HTTP GET і POST?

Мета

• GET запитує представлення ресурсу. За специфікацією він доступний лише для читання: клієнт не очікує жодних змін стану сервера. RFC 9110 зазначає, що надсилання тіла в запиті GET має невизначену семантику, тому GET не повинен містити тіло.
• POST просить цільовий ресурс обробити дані, що містяться в тілі запиту, відповідно до власної семантики цього ресурсу (створити запис, надіслати форму, завантажити файл тощо).

Куди йдуть дані

• GET містить параметри в рядку запиту URL-адреси (після ?, у форматі key=value&...). Вони відображаються в адресному рядку та записуються в історію веб-переглядача та журнали сервера, а також обмежені практичним обмеженням довжини URL-адреси.
• POST переносить дані в тіло запиту; тип задається заголовком Content-Type. HTML-форми зазвичай використовують application/x-www-form-urlencoded (за замовчуванням) або multipart/form-data (для файлів). Немає фіксованого обмеження розміру на рівні протоколу, але сервери та проксі налаштовують власні максимуми (наприклад, Nginx client_max_body_size).

Властивості відповідно до RFC 9110

• Безпечно: GET є безпечним (тільки для читання); POST не є.
• Ідемпотентний: запит є ідемпотентним, якщо виконання його N разів має такий самий вплив на стан сервера, як і одноразове виконання. GET є ідемпотентним; POST не є — повторення може створити дублікати, наприклад два ідентичних замовлення. Ідемпотент – це не те ж саме, що безпечний (PUT і DELETE є ідемпотентними, але не безпечними), і це нічого не говорить про ідентичність тіла відповіді.
• Кешувати: відповіді GET кешуються за замовчуванням; Відповіді POST можна кешувати лише тоді, коли вони містять явну інформацію про свіжість і відповідний заголовок Content-Location, що рідко зустрічається на практиці.

Практичні наслідки

• Використовуйте GET для пошуку та навігації; результати можна безпечно повторити, додати в закладки та попередньо вибрати, а оновлення сторінки GET нешкідливо.
• Використовуйте POST для дій зі зміною стану та для надсилання конфіденційних або великих корисних даних. Оновлення або перехід назад до сторінки POST запускає попередження браузера «підтвердити повторне надсилання форми».
• Ніколи не надсилайте паролі через GET — вони потраплять у URL-адресу, журнали та історію. Це гігієна, а не шифрування: HTTPS шифрує як URL-адресу, так і тіло під час передавання, але URL-адреса все ще реєструється.

Загальні подальші дії

• Безпечними методами є GET, HEAD, OPTIONS; ідемпотентними методами є GET, HEAD, PUT, DELETE; POST не є ні тим, ні іншим.
• Обидва методи підтримуються формами HTML (атрибут method).
• «Безпечний» у сенсі RFC означає відсутність зміни стану, а не захист даних.
• Ідемпотентність POST на рівні програми часто забезпечується за допомогою ключів ідемпотентності.