Відповіді:
HTTP PUT:
PUT розміщує файл або ресурс у певному URI та саме в цьому URI. Якщо в цьому URI вже є файл або ресурс, PUT замінює цей файл або ресурс. Якщо там немає файлу чи ресурсу, PUT створює його. PUT ідентичний , але парадоксально відповіді PUT не підлягають кешуванню.
HTTP 1.1 розташування RFC для PUT
HTTP POST:
POST надсилає дані до конкретного URI і очікує, що ресурс у цьому URI буде обробляти запит. Веб-сервер в цей момент може визначити, що робити з даними в контексті вказаного ресурсу. Метод POST не є ідентичним , однак відповіді POST є кешованими до тих пір, поки сервер встановить відповідні заголовки кеша-керування та закінчується.
Офіційний HTTP RFC визначає POST:
Місце розташування HTTP 1.1 RFC для POST
Різниця між POST та PUT:
Сама RFC пояснює основну різницю:
Принципова відмінність запитів POST від PUT відображається в різному значенні Request-URI. URI у запиті POST ідентифікує ресурс, який буде обробляти додану сутність. Цей ресурс може бути процесом прийняття даних, шлюзом до якогось іншого протоколу або окремим об'єктом, який приймає примітки. На відміну від цього, URI у запиті PUT ідентифікує об'єкт, укладений із запитом - агент користувача знає, для чого призначений URI, і сервер НЕ МОЖЕ намагатися застосувати запит до якогось іншого ресурсу. Якщо сервер бажає, щоб запит було застосовано до іншого URI, він ОБОВ'ЯЗКОВО надішле відповідь 301 (переміщений постійно); користувальницький агент МОЖЕ приймати власне рішення щодо перенаправлення запиту чи ні.
Крім того, і трохи більш стисло, RFC 7231, розділ 4.3.4, стан PUT (наголос додано),
4.3.4. ПУТ
Метод PUT вимагає, щоб стан цільового ресурсу був
createdабоreplacedстаном, визначеним представленням, доданим до корисного навантаження повідомлення запиту.
Використовуючи правильний метод, не пов'язаний убік:
Однією з переваг REST ROA проти SOAP є те, що при використанні HTTP REST ROA він заохочує до правильного використання дієслів / методів HTTP. Так, наприклад, ви використовуєте PUT лише тоді, коли хочете створити ресурс саме в цьому місці. І ви ніколи не використовуєте GET для створення чи зміни ресурсу.
If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI. Отже, реалізація PUT, яка відмовляється створити ресурс, якщо її немає, буде правильною, правда? Якщо так, чи трапляється це на практиці? Або реалізації зазвичай також створюються на PUT?
Тільки семантика.
HTTP PUTповинен прийняти тіло запиту, а потім зберігати його на ресурсі, визначеному URI.
HTTP POSTє більш загальним. Він повинен ініціювати дію на сервері. Ця дія може полягати в збереженні тіла запиту на ресурсі, визначеному URI, або це може бути інший URI, або це може бути інша дія.
PUT - це як завантаження файлу. Набір на URI впливає саме на цей URI. POST на URI може взагалі мати будь-який ефект.
Щоб навести приклади ресурсів у стилі REST:
"POST / books" з купою інформації про книгу може створити нову книгу та відповісти новою URL-адресою, що ідентифікує цю книгу: "/ books / 5".
"PUT / книги / 5" повинні були або створити нову книгу з ідентифікатором 5, або замінити існуючу книгу на ID 5.
У нересурсовому стилі POST можна використовувати майже для всього, що має побічний ефект. Ще одна відмінність полягає в тому, що PUT повинен бути ідентичним - декілька PUT одних і тих же даних на одну і ту ж URL-адресу має бути нормальним, оскільки кілька POST можуть створювати кілька об'єктів або все, що це робить ваша POST-дія.
PUT розуміється як метод "завантаження" матеріалів до певного URI або перезапису того, що вже є в цьому URI.
З іншого боку, POST - це спосіб подання даних, пов'язаних із заданим URI.
Зверніться до HTTP RFC
Наскільки я знаю, PUT використовується в основному для оновлення записів.
POST - для створення документа або будь-якого іншого ресурсу
PUT - для оновлення створеного документа або будь-якого іншого ресурсу.
Але щоб було зрозуміло, що PUT зазвичай 'замінює' існуючий запис, якщо він є, і створює, якщо його немає там.
Інші вже розмістили чудові відповіді, я просто хотів додати, що з більшістю мов, фреймворків та випадків використання ви будете мати справу з POST набагато частіше, ніж PUT. До того, як PUT, DELETE тощо - це, по суті, дрібниці.
Перегляньте: http://zacharyvoase.com/2009/07/03/http-post-put-diff/
Останнім часом я сильно роздратований популярною помилковою думкою веб-розробників, що POST використовується для створення ресурсу, а PUT використовується для його оновлення / зміни.
Якщо ви подивитесь на сторінку 55 RFC 2616 ("Протокол передачі гіпертексту - HTTP / 1.1"), розділ 9.6 ("PUT"), ви побачите, що насправді означає PUT:
Метод PUT вимагає, щоб вкладений об'єкт зберігався під наданим URI-запитом.
Також є зручний пункт для пояснення різниці між POST та PUT:
Принципова відмінність запитів POST від PUT відображається в різному значенні Request-URI. URI у запиті POST ідентифікує ресурс, який буде обробляти додану сутність. Цей ресурс може бути процесом прийняття даних, шлюзом до якогось іншого протоколу або окремим об'єктом, який приймає примітки. На відміну від цього, URI у запиті PUT ідентифікує об'єкт, укладений із запитом - агент користувача знає, що призначений URI, і сервер НЕ МОЖЕ намагатися застосувати запит до якогось іншого ресурсу.
У ньому нічого не згадується про різницю між оновленням / створенням, адже це не про що. Мова йде про різницю між цим:
obj.set_attribute(value) # A POST request.
І це:
obj.attribute = value # A PUT request.
Тож, будь ласка, припиніть поширення цієї популярної помилки. Прочитайте свої RFC.
POST вважається чимось методом заводського типу. Ви включаєте в нього дані, щоб створити те, що ви хочете, і все, що знаходиться на іншому кінці, знає, що з цим робити. PUT використовується для оновлення існуючих даних за вказаною URL-адресою або для створення чогось нового, коли ви знаєте, яким буде URI, і він вже не існує (на відміну від POST, який щось створить і поверне URL-адресу це при необхідності).
REST просить розробників використовувати методи HTTP явно і таким чином, що відповідає визначенню протоколу. Цей базовий принцип проектування REST встановлює індивідуальне відображення між операціями створення, читання, оновлення та видалення (CRUD) та методами HTTP. Відповідно до цього відображення:
• Щоб створити ресурс на сервері, використовуйте POST.
• Щоб отримати ресурс, використовуйте GET.
• Щоб змінити стан ресурсу або оновити його, використовуйте PUT.
• Щоб видалити або видалити ресурс, використовуйте DELETE.
Більше інформації: RESTful Web Services: основи від IBM
Коли слід вживати те чи інше, має бути досить зрозуміло, але складні висловлювання є причиною плутанини для багатьох із нас.
Використовуйте, PUTколи ви хочете змінити особливий ресурс, який вже є частиною збору ресурсів. PUTзамінює ресурс у повному обсязі. Приклад:PUT /resources/:resourceId
Sidenote: використовуйте, PATCHякщо ви хочете оновити частину ресурсу.
POSTколи ви хочете додати дочірній ресурс під колекцію ресурсів. POST => /resourcesPUTдля операцій UPDATE .POSTдля CREATE операцій.GET / компанія / звіти => Отримати всі звіти
GET / компанія / звіти / {id} => Отримати інформацію звіту за допомогою "id"
POST / компанія / звіти => Створити новий звіт
PUT / компанія / звіти / {id} => Оновити інформація звіту, ідентифікована "id"
PATCH / компанія / звіти / {id} => Оновити частину інформації звіту, ідентифіковану "id"
DELETE / компанія / звіти / {id} => Видалити звіт за "id"
Різниця між POST та PUT полягає в тому, що PUT ідентичний, це означає, що виклик одного і того ж запиту PUT декілька разів завжди призведе до того ж результату (що не є побічним ефектом), а з іншого боку, повторний виклик POST-запиту ( додаткові) побічні ефекти створення одного і того ж ресурсу кілька разів.
GET : Запити, що використовують GET лише для отримання даних, тобто вимагає представлення зазначеного ресурсу
POST: Він посилає дані на сервер для створення ресурсу. Тип тіла запиту вказується заголовком Content-Type. Це часто викликає зміну стану або побічні ефекти на сервері
PUT : Створює новий ресурс або замінює представлення цільового ресурсу з корисним навантаженням запиту
PATCH : Він використовується для застосування часткових модифікацій до ресурсу
DELETE : Він видаляє вказаний ресурс
TRACE : Він виконує тест зворотної передачі повідомлень по шляху до цільового ресурсу, забезпечуючи корисний механізм налагодження
OPTIONS : Він використовується для опису параметрів зв'язку для цільового ресурсу, клієнт може вказати URL-адресу методу OPTIONS або зірочку (*) для позначення всього сервера.
HEAD : Він вимагає відповіді, ідентичного відповіді на запит GET, але без органу відповіді
CONNECT : Він встановлює тунель до сервера, ідентифікований цільовим ресурсом, може використовуватися для доступу до веб-сайтів, які використовують SSL (HTTPS)
ПОВЕРНЕННЕ використання
POST використовується для створення нового ресурсу, а потім повертає ресурс URI
EX
REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}
Цей дзвінок може створити нову книгу та поверне її URI
Response ...THE-NEW-RESOURCE-URI/books/5
PUT використовується для заміни ресурсу, якщо цей ресурс існує, тоді просто оновіть його, але якщо цього ресурсу не існує, тоді створіть його,
REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}
З PUTми знаємо , ідентифікатор ресурсу, але POSTповертає новий ідентифікатор ресурсу
Без використання REST-повного використання
POST використовується для ініціювання дії на стороні сервера, ця дія може або не може створити ресурс, але ця дія матиме сторону, яка впливає завжди, вона щось змінить на сервері
PUT використовується для розміщення або заміни буквального контенту за певною URL-адресою
Ще одна відмінність як стилів REST-ful, так і не REST-ful
POST є неідентичною операцією: це призведе до деяких змін, якщо виконується кілька разів з одним і тим же запитом.
PUT - Idempotent Operation: вона не матиме побічних ефектів, якщо виконуватися кілька разів з одним і тим же запитом.
Варто зазначити, що POSTпіддаються деяким загальним нападкам підробки між веб-сайтами (CSRF), хоча PUTце не так.
Наведений нижче CSRF неможливий,PUT коли жертва відвідує attackersite.com.
Ефект атаки є те , що жертва ненавмисно видаляє користувач тільки тому , що вона (жертва) була зареєстрована в якості adminна target.site.com, перед відвідуванням attackersite.com:
Звичайний запит (куки надсилаються): ( PUTне підтримується значення атрибута)
Код на attackersite.com:
<form id="myform" method="post" action="http://target.site.com/deleteUser" >
<input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>
XHR-запит (файли cookie надсилаються): ( PUTвикликав би попередній запит, відповідь якого не дозволить браузеру запитувати deleteUserсторінку)
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);
Простими словами ви можете сказати:
1.HTTP Get: використовується для отримання одного або декількох предметів
2.HTTP-повідомлення: використовується для створення елемента
3.HTTP Put: використовується для оновлення елемента
4.HTTP-патч: використовується для часткового оновлення елемента
5.HTTP Видалення: використовується для видалення елемента
Насправді немає різниці, крім їх назви. Насправді є основна різниця між GET та іншими. За допомогою методу "GET" -Request ви надсилаєте дані в рядку URL-адреси, які розділяються спочатку знаком питання, а потім знаком &.
Але з методом "POST" -запит, ви не можете передавати дані через URL, але вам потрібно передавати дані як об'єкт у так званому "тілі" запиту. На стороні сервера ви повинні прочитати тіло отриманого вмісту, щоб отримати надіслані дані. Але з іншого боку немає можливості надсилати вміст у тілі, коли ви надсилаєте "GET" -запит.
Твердження, що "GET" призначений лише для отримання даних, а "POST" - для розміщення даних, абсолютно помилкове. Ніхто не може перешкодити вам створювати новий вміст, видаляти наявний вміст, редагувати наявний вміст або робити що-небудь у сервісному інтерфейсі на основі даних, що надсилаються за запитом "GET" або за запитом "POST". І ніхто не може перешкодити вам кодувати бекенд таким чином, що за допомогою "POST" -запит клієнт запитує деякі дані.
Запитуючи, незалежно від того, яким методом ви користуєтесь, ви телефонуєте за URL-адресою та надсилаєте чи не надсилаєте деякі дані, щоб вказати, яку інформацію ви хочете передати серверу, щоб вирішити ваш запит, і тоді клієнт отримує відповідь від сервер. Дані можуть містити все, що ви хочете надіслати, бекенду дозволено робити все, що завгодно, з даними, і відповідь може містити будь-яку інформацію, яку ви хочете внести туди.
Є лише ці два ОСНОВНІ МЕТОДИ. Отримати та відправити. Але саме їх структура відрізняє їх, а не те, що ви кодуєте в бекенді. У бекенді ви можете кодувати все, що завгодно, з отриманими даними. Але із запитом "POST" вам потрібно буде надіслати / отримати дані в тілі, а не в URL-адресі, а із запитом "GET" вам потрібно буде надіслати / отримати дані в URL-адресі, а не в тіло. Це все.
Усі інші методи, такі як "PUT", "DELETE" тощо, мають таку ж структуру, що і "POST".
Метод POST використовується в основному, якщо ви хочете дещо приховати вміст, оскільки все, що ви пишете в URL-адресі, це буде збережено в кеш-пам'яті, а метод GET - це те саме, що і написання URL-адреси з даними. Отже, якщо ви хочете надіслати конфіденційні дані, які не завжди обов'язково мають ім'я користувача та пароль, але, наприклад, деякі ідентифікатори чи хеші, які не потрібно відображати в URL-адресі-рядку, тоді ви повинні використовувати метод POST .
Також довжина URL-адреси обмежена 1024 символами, тоді як "POST" -метод не обмежений. Отже, якщо у вас є більший обсяг даних, ви, можливо, не зможете надіслати їх за допомогою GET-Request, але вам потрібно буде використовувати POST-Request. Тож це також ще один плюс для POST-запиту.
Але працювати з GET-запитом набагато простіше, коли у вас немає складного тексту для надсилання. В іншому випадку, і це ще один плюс у методі POST, полягає в тому, що за допомогою GET-методу вам потрібно url-кодувати текст, щоб мати можливість надсилати деякі символи всередині тексту чи навіть пробілів. Але за допомогою методу POST у вас немає обмежень, і ваш вміст ні в якому разі не потрібно змінювати чи маніпулювати.
І PUT, і POST - це методи відпочинку.
PUT - Якщо ми зробимо один і той же запит двічі, використовуючи PUT, використовуючи однакові параметри обидва рази, другий запит не матиме жодного ефекту. Ось чому PUT зазвичай використовується для сценарію оновлення, виклик оновлення більше одного разу з тими ж параметрами не робить нічого більше, ніж початковий виклик, отже PUT є ідентичним.
POST не є idempotent, наприклад, Create створить дві окремі записи в ціль, отже, це не idempotent, тому CREATE широко використовується в POST.
Здійснення одного і того ж дзвінка з використанням POST з однаковими параметрами щоразу спричиняє дві різні речі, отже чому POST зазвичай використовується для створення сценарію