У чому головна відмінність запиту PATCH від PUT?


187

Я використовую PUTзапит у своїй програмі Rails. Тепер PATCHбраузер реалізував нову версію HTTP . Отже, я хочу знати , що основна відмінність між PATCHі PUTзапити, і коли ми повинні використовувати один або інший.

Відповіді:


139

Дієслова HTTP - це, мабуть, одна з найкриптичніших речей про протокол HTTP. Вони існують, і їх багато, але чому вони існують?

Здається, Rails хоче підтримувати багато дієслів і додавати деякі дієслова, які не підтримуються веб-браузерами.

Ось вичерпний список дієслів http: http://annevankesteren.nl/2007/10/http-methods

Там патч HTTP від ​​офіційного RFC: https://datatracker.ietf.org/doc/rfc5789/?include_text=1

Метод PATCH просить застосувати набір змін, описаних в об'єкті запиту, до ресурсу, ідентифікованого запитом-URI. Набір змін представлений у форматі, який називається "патч-документ", ідентифікований носієм типу. Якщо Request-URI не вказує на існуючий ресурс, сервер МОЖЕ створити новий ресурс, залежно від типу патч-документа (чи може він логічно змінювати нульовий ресурс) та дозволів тощо.

Різниця між запитами PUT та PATCH відображається в тому, як сервер обробляє додану сутність для зміни ресурсу, визначеного Request-URI. У запиті PUT вкладений об'єкт вважається модифікованою версією ресурсу, що зберігається на початковому сервері, і клієнт вимагає замінити збережену версію. Однак із PATCH додане об'єднання містить набір інструкцій, що описують, як ресурс, що перебуває в даний час на початковому сервері, повинен бути модифікований для створення нової версії. Метод PATCH впливає на ресурс, визначений Request-URI , і він також МОЖЕмають побічні ефекти на інші ресурси; тобто нові ресурси можуть бути створені або модифіковані існуючі за допомогою застосування PATCH .

Наскільки я знаю, дієслово PATCH не використовується так, як це є в рейлових програмах ... Як я розумію, слід дієслово виправлення RFC використовувати для надсилання інструкцій з патчем, як, наприклад, коли ви робите відмінності між двома файлами. Замість того, щоб ще раз надсилати цілу сутність, ви надсилаєте виправлення, яке може бути набагато меншим, ніж повторне повторення цілої сутності.

Уявіть, що ви хочете відредагувати величезний файл. Ви редагуєте 3 рядки. Замість того, щоб надсилати файл назад, потрібно просто надіслати розл. З іншого боку, надіслати запит на виправлення можна використовувати для асинхронного об'єднання файлів. Система контролю версій потенційно може використовувати дієслово PATCH для віддаленого оновлення коду.

Ще один можливий випадок використання дещо пов'язаний з базами даних NoSQL, можливо зберігання документів. Скажімо, ми використовуємо структуру JSON для передачі даних із сервера клієнту. Якби ми хотіли видалити поле, ми могли б використати синтаксис, подібний до того, що в mongodb, для $ unset . Насправді метод, використовуваний у mongodb для оновлення документів, можливо, може бути використаний для обробки патчів json.

Беручи цей приклад:

db.products.update(
   { sku: "unknown" },
   { $unset: { quantity: "", instock: "" } }
)

У нас може бути щось подібне:

PATCH /products?sku=unknown
{ "$unset": { "quantity": "", "instock": "" } }

І останнє, але не менш важливе, люди можуть говорити, що вони хочуть, про HTTP дієслова. Є лише одна правда, і правда є в РФС.


1
Важливо зауважити, що RFC 5789 все ще знаходиться у фазі пропозицій і офіційно не прийнятий, і в даний час позначений як "irrata postoji". Ця "найкраща практика" є дуже дискусійною, і технічно PATCH ще не є частиною стандарту HTTP. Єдина правда тут полягає в тому, що оскільки RFC не прийнято, ви не повинні цього робити.
fishpen0

3
Навіть якщо він все ще є у пропозиції, це не означає, що його не слід використовувати. Якби це було так, ми б не змогли використовувати веб-розетки та багато інших rfcs, які все ще є у пропозиції ... Реалізація пропозиції є в 100 разів кращою, ніж реалізація чогось повністю на замовлення, що ніхто інший не реалізує.
Loïc Faure-Lacroix

BS. Це не "в пропозиції", і це частина стандарту HTTP (стандарт RFC 7231 делегує до реєстру IANA методи, і PATCH тут вказаний).
Джуліан Решке

@JulianReschke, якщо ви прочитаєте другий рядок цього RFC, ви побачите, що він як і раніше позначений як ПРЕДЛОЖЕНИЙ СТАНДАРТ . Так ні, метод патча все ще є у пропозиції. Тут є rfc. tools.ietf.org/html/rfc5789 та rfc7231 також ПРЕДЛОЖЕНИЙ СТАНДАРТ . Якщо подивитися, наприклад, RFC821, він позначений як INTERNET STANDARD
Loïc Faure-Lacroix

1
@JulianReschke en.wikipedia.org/wiki/Internet_Standard#Proposed_Standard ... Це не моє слово. Запропонований стандарт не означає, що ви не можете його добре реалізувати, як я пояснив вище. Це не означає, що він недостатньо стабільний для впровадження ... але він все ще є у пропозиції, якщо він не позначений як Internet Standard ... Я не впевнений, як ви сперечаєтесь з цим. Це називається "запропонований стандарт", це не може означати нічого іншого, крім пропозиції. Якщо ви хочете стверджувати, що запропонований стандарт може бути використаний. Це саме те, що я написав.
Loïc Faure-Lacroix

104

Я провела пару годин з Google і знайшла відповідь тут

PUT => Якщо користувач може оновити всю або лише частину запису , використовуйте PUT (користувач контролює оновлення)

PUT /users/123/email
new.email@example.org

PATCH => Якщо користувач може оновити лише частковий запис , сказати лише адресу електронної пошти (програма контролює те, що можна оновити), використовуйте PATCH.

PATCH /users/123
[description of changes]

Чому? Patch

PUTметоду потрібно більше пропускної здатності або обробляти повні ресурси, а не часткові. Так PATCHбуло введено для зменшення пропускної здатності.

Пояснення щодо PATCH

PATCH це метод, який не є безпечним і не є ідентичним, і дозволяє отримати повне та часткове оновлення та побічні ефекти для інших ресурсів.

PATCH - це метод, укладений об'єкт містить набір інструкцій, що описують, як ресурс, що перебуває в даний час на початковому сервері, повинен бути змінений для отримання нової версії.

PATCH /users/123
[
  { "op": "replace", "path": "/email", "value": "new.email@example.org" }
]

Тут більше інформації про put і patch


7
Чому цей ПАТЧ не безпечний?
Bishisht Bhatta

1
PATCHсеред POST, і PUTтак далі не «безпечно», тому що він змінює свої дані (має побічні ефекти). За порівнянні з GET, і OPTIONSтак далі (безпечними методами) , де ви можете назвати кінцеві точки кілька разів без будь - яких побічних ефектів.
emix

1
PATCH НЕ вводився виключно для збереження пропускної здатності. Як зазначає RFC 5789:> "Необхідний новий метод для поліпшення сумісності та запобігання помилкам." У кількох паралельних умовах наявність лише PUT, які включають решту корисного навантаження, збільшує ризик зміни інших атрибутів ресурсу. PATCH вирішує таку проблему.
Томаш Назар

43

ставити
, якщо я хочу змінити firstім'я потім відправити пута запиту на оновлення

{ "first": "Nazmul", "last": "hasan" } 

але тут є одна проблема - це putзапит, що коли я хочу надіслати putзапит, я повинен надіслати всі два параметри, які є, firstі last
тому обов'язково знову надіслати все значення

патч :
patchзапит каже. надсилайте лише той, dataякий ви хочете, updateі він не впливає або не змінює інші дані.
тому не потрібно надсилати все значення знову. просто я хочу оновити своє ім'я, тому мені потрібно надіслати лише firstім'я для оновлення.


13

Ось різниця між методами POST, PUT та PATCH протоколу HTTP.

ПОШТА

Метод HTTP.POST завжди створює новий ресурс на сервері. Це неідентичний запит, тобто якщо користувач звертається до одних і тих же запитів 2 рази, він створить ще один новий ресурс, якщо немає обмежень.

Метод http post - це як запит INSERT в SQL, який завжди створює нову запис у базі даних.

Приклад: Використовуйте метод POST для збереження нового користувача, замовлення тощо, де сервер сервера вирішує ідентифікатор ресурсу для нового ресурсу.

ПУТ

У методі HTTP.PUT ресурс спочатку ідентифікується з URL-адреси, а якщо він існує, то він оновлюється, інакше створюється новий ресурс. Коли цільовий ресурс існує, він замінює цей ресурс повністю новим тілом. Тобто метод HTTP.PUT використовується для створення або оновлення ресурсу.

Метод http put - це як запит MERGE в SQL, який вставляє або оновлює запис залежно від того, чи існує даний запис.

PUT-запит ідентичний, тобто натискання на ті самі запити двічі оновить існуючу запис (не створено нової записи). У методі PUT ідентифікатор ресурсу визначається клієнтом і надається в URL-адресі запиту.

Приклад: Використовуйте метод PUT для оновлення наявного користувача або замовлення.

ПАТЧ

Метод HTTP.PATCH використовується для часткових модифікацій ресурсу, тобто оновлення дельти.

Метод http patch - це як запит UPDATE в SQL, який встановлює або оновлює лише вибрані стовпці, а не весь рядок.

Приклад: ви можете використовувати метод PATCH для оновлення стану замовлення.

PATCH / api / користувачів / 40450236 / замовлення / 10234557

Орган запиту: {статус: 'Доставлено'}


Це найгірше пояснення, про яке хто-небудь міг прочитати про нанесення та виправлення. І крім того, після стількох хороших відповідей, які вже були опубліковані, що змушує вас вважати, що ваша відповідь тут інша?
CodeHunter

3

Є обмеження в режимі PUT над PATCH під час оновлення. Використання PUT вимагає, щоб ми вказали всі атрибути, навіть якщо ми хочемо змінити лише один атрибут. Але якщо ми використовуємо метод PATCH, ми можемо оновлювати лише потрібні нам поля, і не потрібно згадувати всі поля. PATCH не дозволяє нам змінювати значення в масиві або видаляти атрибут або запис масиву.


1

Методи PUT і PATCH за своєю суттю схожі, але є ключова відмінність.

PUT - у запиті PUT додане об'єкт буде розглядатися як модифікована версія ресурсу, який знаходиться на сервері, і його буде замінено цим модифікованим об'єктом.

PATCH - у запиті PATCH додане об'єднання містить набір інструкцій про те, як сутність, що знаходиться на сервері, буде модифікована для отримання нової версії.


1

Згідно з умовами HTTP, PUTзапит є подібно до заяви про оновлення бази даних. PUT- використовується для модифікації існуючого ресурсу (раніше POSTED). З іншого боку, PATCHзапит використовується для оновлення деякої частини існуючого ресурсу.

Наприклад:

Інформація про клієнта:

// This is just a example.

firstName = "James";
lastName = "Anderson";
email = "email@domain.com";
phoneNumber = "+92 1234567890";
//..

Коли ми хочемо оновити весь запис? ми повинні використовувати Http PUT verbдля цього.

як от:

// Customer Details Updated.

firstName = "James++++";
lastName = "Anderson++++";
email = "email@Updated.com";
phoneNumber = "+92 0987654321";
//..

З іншого боку, якщо ми хочемо оновити лише частину запису, а не весь запис, тоді переходимо Http PATCH verb. як от:

   // Only Customer firstName and lastName is Updated.

    firstName = "Updated FirstName";
    lastName = "Updated LastName";
   //..

ВИПУСК проти пошти:

Під час використання PUTзапиту ми мусимо надсилати всі параметри, такі як firstName, lastName, email, phoneNumber Where as In In, patchнадіслати лише ті параметри, який ми хочемо оновити, і він не впливає та не змінює інші дані.

Для отримання більш детальної інформації відвідайте: https://fullstack-developer.academy/restful-api-design-post-vs-put-vs-patch/


0

Метод Put і Patch схожий. Але в рейках він має інший метод. Якщо ми хочемо оновити / замінити весь запис, тоді ми повинні використовувати метод Put. Якщо ми хочемо оновити конкретний запис, використовуємо метод Patch.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.