POST (HTTP)

POST — один з багатьох методів запиту, що підтримуються протоколом передачі даних HTTP, який використовується у всесвітній мережі Інтернет. Метод POST призначений для запиту, при якому вебсервер приймає дані збережені в тілі повідомлення, для зберігання. Метод часто використовується для завантаження файлу або передачі заповненої вебформи.

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

Дані POST-запитів

Всесвітня мережа Інтернет і протокол 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. Це формат для кодування пар ключ-значення з можливістю дублювання ключів. Кожна пара ключ-значення відділяється символом &, ключ відділений від значення символом =. У ключах і значеннях пробіли замінюються на символ +, і потім, використовуючи URL-кодування, замінюються всі не літеро-цифрові символи.

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.

Примітки

1. . Архів оригіналу за 25 травня 2017. Процитовано 24 липня 2014. «The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.»  
2. Berners-Lee, Tim; Connolly, Dan (22 вересня 1995). . World Wide Web Consortium. Архів оригіналу за 25 грудня 2010. Процитовано 15 січня 2011. 
3. . Архів оригіналу за 3 вересня 2008. Процитовано 28 березня 2017.