POST

Метод POST вимагає від цільового ресурсу обробити представлення, що міститься в запиті, відповідно до власної семантики ресурсу. Наприклад, POST використовується для таких функцій (серед інших):

• Надання блоку даних, наприклад, полів, введених у HTML-форму, процесу обробки даних;
• Опублікування повідомлення на дошці оголошень, у групі новин, списку розсилки, блозі або подібній групі статей;
• Створення нового ресурсу, який ще не ідентифіковано сервером-джерелом;
• Додавання даних до наявного представлення ресурсу.

Сервер-джерело вказує семантику відповіді, вибираючи відповідний код стану залежно від результату обробки POST-запиту; майже всі коди стану, визначені цією специфікацією, можуть бути отримані у відповіді на POST (винятками є 206 (Частковий вміст), 304 (Не змінено) і 416 (Діапазон не задовольняє)).

Якщо один або кілька ресурсів було створено на сервері-джерелі в результаті успішної обробки POST-запиту, сервер-джерело ПОВИНЕН надіслати відповідь 201 (Створено), що містить поле заголовка Location, яке надає ідентифікатор створеного первинного ресурсу (Розділ 7.1.2) та представлення, яке описує стан запиту, посилаючись на новий ресурс(и).

Відповіді на POST-запити можна кешувати лише тоді, коли вони містять явну інформацію про свіжість (див. розділ 4.2.1 [RFC7234]). Однак, кешування POST не є широко розповсюдженим. У випадках, коли сервер-джерело бажає, щоб клієнт міг кешувати результат POST таким чином, щоб його можна було повторно використати у наступному GET, сервер-джерело МОЖЕ надіслати відповідь 200 (OK), що містить результат і поле заголовка Content-Location, яке має те саме значення, що й ефективний URI запиту POST (Розділ 3.1.4.2).

Якщо результат обробки POST буде еквівалентним представленню існуючого ресурсу, сервер-джерело МОЖЕ перенаправити агента користувача до цього ресурсу, надіславши відповідь 303 (Див. Інше) з ідентифікатором існуючого ресурсу у полі Location. Це має переваги надання агенту користувача ідентифікатора ресурсу і передачі представлення за допомогою методу, більш придатного для спільного кешування, хоча і за рахунок додаткового запиту, якщо агент користувача ще не має кешованого представлення.