POST (HTTP)

Всесвітня мережа Інтернет і протокол HTTP базуються на методах запитів, включаючи POST, GET, PUT, DELETE і ряд інших. Веббраузери зазвичай використовують тільки GET і POST, але REST онлайн-додатки вимагаються підтримки і багатьох інших. Метод POST призначений для відправки запиту нової сутності на сервер, так що вона буде зберігатися як підресурс ресурсу, ідентифікованого URI. Наприклад, для URI http://example.com/customers за допомогою POST запитів можна було б представляти нових клієнтів, кожен з яких містив би ім'я, адресу та контактні дані. Розробники сайтів відійшли від цієї концепції з двох причин. По-перше, немає ніяких технічних причин для URI текстуально описувати підлеглі веб-ресурси, на яких будуть збережені дані послані методом POST. Справді, остання частина URI більш ймовірно опише сторінку обробки веб-додатку та його технології, наприклад http://example.com/applicationform.php. По-друге, з огляду на природне обмеження більшості веб-браузерів роботи тільки методами GET та POST, розробники розуміли необхідність додавання додаткових можливостей в метод POST, включаючи зміну існуючих записів та їх видалення.

Спроби виправити перший недолік почалися ще в 1998 році. Фреймворки веб-додатків, такі як Ruby on Rails та інші допомагали розробникам надавати своїм користувачам веб-адреси, зручні для сприйняття людиною. Що стосується другого пункту, можна написати клієнтські сценарії або автономні програми, які будуть використовувати інші методи HTTP, перетворюючи їх потім в метод POST.

Тобто не можна сказати, що кожна веб-форма повинна містити метод POST в відкриваючому тезі. Чимало форм використовуються для більш точно для отримання інформації з серверу, без зміни основних баз даних. Для таких форм пошуку ідеально підходить метод GET.

Бувають випадки, коли HTTP GET не підходить навіть для отримання даних. Прикладом є ситуація, коли велика кількість даних має бути записана в URL. Браузери і веб-сервери можуть мати обмеження на довжину URL, які вони обробляють без помилки. URL-кодування зарезервованих символів у адресі і рядку запиту може значно збільшити довжину, в той час як HTTP-сервер Apache може обробляти до 4000 символів в URL, Microsoft Internet Explorer обмежує довжину будь-якого URL 2048 символами.

Так само, HTTP GET не повинен використовуватися для конфіденційної інформації, такої як імена користувачів і паролі, які повинні бути представлені разом з іншими даними для завершення запиту. Навіть при використанні HTTPS, що запобігає дані від перехоплення при передачі, історії браузера і журнали веб-сервера, ймовірно, містять повні URLи у вигляді відкритого тексту, що можуть бути знайдені, якщо система буде зламана. У цих випадках використовується HTTP POST.

Коли веб-браузер відправляє POST-запит з елементами веб-форми, за умовчанням інтернет-тип даних медіа це: application/x-www-form-urlencoded.[2] Це формат для кодування пар ключ-значення з можливістю дублювання ключів. Кожна пара ключ-значення відділяється символом &, ключ відділений від значення символом =. У ключах і значеннях пробіли замінюються на символ +, і потім, використовуючи URL-кодування, замінюються всі не літеро-цифрові символи.[3]

Name: Jonathan Doe
Age: 23
Formula: a + b == 13 %!

Буде закодовано таким чином:

Name=Jonathan+Doe&Age=23&Formula=a+%2B+b+%3D%3D+13+%25%21

Починаючи з HTML 4.0, форми можуть також представити дані в multipart/form, як визначено в RFC 2388 (див. Також RFC 1867 для більш ранньої експериментальної версії визначеної як розширення HTML 2.0 і згадується в HTML 3.2).

Окремий випадок методу POST при зверненні на ту ж сторінку, якій належить форма, називається зворотньою передачею.

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

Тим не менш, є причини чому POST використовується навіть для ідемпотентних запитів, особливо у випадках коли запит використовує не-ASCII символи або дуже довгий, через обмеження на URL.