Sự khác biệt chính giữa yêu cầu PATCH và PUT là gì?


185

Tôi đang sử dụng một PUTyêu cầu trong ứng dụng Rails của tôi. Bây giờ, một động từ HTTP mới, PATCHđã được các trình duyệt triển khai. Vì vậy, tôi muốn biết sự khác biệt chính giữa PATCHPUTyêu cầu là gì và khi nào chúng ta nên sử dụng cái này hay cái khác.

Câu trả lời:


138

Động từ HTTP có lẽ là một trong những điều khó hiểu nhất về giao thức HTTP. Chúng tồn tại, và có rất nhiều trong số chúng, nhưng tại sao chúng tồn tại?

Rails dường như muốn hỗ trợ nhiều động từ và thêm một số động từ không được hỗ trợ bởi các trình duyệt web nguyên bản.

Dưới đây là danh sách đầy đủ các động từ http: http://annevankesteren.nl/2007/10/http-methods

Có bản vá HTTP từ RFC chính thức: https://datatracker.ietf.org/doc/rfc5789/?include bản = 1

Các PATCH yêu cầu phương pháp mà một tập hợp các thay đổi được mô tả trong đơn vị yêu cầu được áp dụng cho các tài nguyên được xác định bởi request- URI. Tập hợp các thay đổi được trình bày theo định dạng gọi là "tài liệu vá" được xác định bởi loại phương tiện. Nếu URI yêu cầu không trỏ đến tài nguyên hiện có, máy chủ CÓ THỂ tạo tài nguyên mới, tùy thuộc vào loại tài liệu vá (liệu nó có thể sửa đổi một cách hợp lý tài nguyên null) và quyền, v.v.

Sự khác biệt giữa các yêu cầu PUTPATCH được phản ánh trong cách máy chủ xử lý thực thể kèm theo để sửa đổi tài nguyên được xác định bởi URI yêu cầu. Trong yêu cầu PUT , thực thể kèm theo được coi là phiên bản sửa đổi của tài nguyên được lưu trữ trên máy chủ gốc và máy khách đang yêu cầu thay thế phiên bản đã lưu trữ. Tuy nhiên, với PATCH , thực thể kèm theo chứa một tập hợp các hướng dẫn mô tả cách một tài nguyên hiện đang cư trú trên máy chủ gốc nên được sửa đổi để tạo ra một phiên bản mới. Các PATCH phương pháp ảnh hưởng đến tài nguyên được xác định bởi Request-URI , và nó cũng THÁNGcó tác dụng phụ trên các tài nguyên khác; tức là, các tài nguyên mới có thể được tạo ra, hoặc các tài nguyên hiện có được sửa đổi, bằng cách áp dụng BCHNG .

Theo như tôi biết, động từ PATCH không được sử dụng như trong các ứng dụng rails ... Theo tôi hiểu điều này, nên sử dụng động từ bản vá RFC để gửi hướng dẫn vá như khi bạn thực hiện khác biệt giữa hai tệp. Thay vì gửi lại toàn bộ thực thể, bạn gửi một bản vá có thể nhỏ hơn nhiều so với gửi lại toàn bộ thực thể.

Hãy tưởng tượng bạn muốn chỉnh sửa một tập tin lớn. Bạn chỉnh sửa 3 dòng. Thay vì gửi lại tệp, bạn chỉ cần gửi diff. Về mặt tích cực, việc gửi yêu cầu vá có thể được sử dụng để hợp nhất các tệp không đồng bộ. Một hệ thống kiểm soát phiên bản có khả năng có thể sử dụng động từ PATCH để cập nhật mã từ xa.

Một trường hợp sử dụng có thể khác có phần liên quan đến cơ sở dữ liệu NoQuery, có thể lưu trữ tài liệu. Giả sử chúng ta sử dụng cấu trúc JSON để gửi qua lại dữ liệu từ máy chủ đến máy khách. Nếu chúng ta muốn xóa một trường, chúng ta có thể sử dụng cú pháp tương tự như cú pháp trong mongodb với $ unset . Trên thực tế, phương pháp được sử dụng trong mongodb để cập nhật tài liệu có thể được sử dụng để xử lý các bản vá json.

Lấy ví dụ này:

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

Chúng ta có thể có một cái gì đó như thế này:

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

Cuối cùng, nhưng không kém phần quan trọng, mọi người có thể nói bất cứ điều gì họ muốn về động từ HTTP. Chỉ có một sự thật và sự thật là ở RFC.


1
Điều quan trọng cần lưu ý là RFC 5789 vẫn đang trong giai đoạn đề xuất và chưa được chấp nhận chính thức và hiện được gắn cờ là "tồn tại bất ổn". 'Cách thực hành tốt nhất' này đang được tranh luận rất nhiều và về mặt kỹ thuật, PATCH chưa phải là một phần của tiêu chuẩn HTTP. Sự thật duy nhất ở đây là vì RFC không được chấp nhận, bạn không nên làm điều đó.
fishpen0

3
Ngay cả khi nó vẫn còn trong đề xuất, điều đó không có nghĩa là nó không nên được sử dụng. Nếu đó là trường hợp, chúng tôi sẽ không thể sử dụng websockets và nhiều rfcs khác vẫn đang trong đề xuất ... Thực hiện đề xuất tốt hơn 100 lần so với thực hiện một cái gì đó hoàn toàn tùy chỉnh mà không ai khác thực hiện.
Loïc Faure-Lacroix

BS. Đó không phải là "trong đề xuất" và đó là một phần của tiêu chuẩn HTTP (tiêu chuẩn, RFC 7231 ủy quyền cho một sổ đăng ký IANA cho các phương thức và PATCH được liệt kê ở đó).
Julian Reschke

@JulianReschke nếu bạn đọc dòng thứ hai của RFC này, bạn sẽ thấy rằng nó vẫn được đánh dấu là TIÊU CHUẨN ĐỀ XUẤT . Vì vậy, không, phương pháp vá vẫn còn trong đề xuất. Các rfc ở đây btw. tools.ietf.org/html/rfc5789 và rfc7231 cũng được TIÊU CHUẨN ĐỀ XUẤT . Nếu bạn nhìn vào RFC821 chẳng hạn, nó được đánh dấu là INTERNET STANDARD
Loïc Faure-Lacroix

1
@JulianReschke en.wikipedia.org/wiki/INET_Stiteria#Proposes_St Chuẩn ... Đó không phải là từ của tôi. Một tiêu chuẩn được đề xuất không có nghĩa là bạn không thể thực hiện nó tốt như tôi đã giải thích ở trên. Điều đó không có nghĩa là nó không đủ ổn định để thực hiện ... nhưng nó vẫn nằm trong đề xuất trừ khi nó được đánh dấu là Tiêu chuẩn Internet ... Tôi không chắc bạn đang tranh luận về điều đó như thế nào. Nó được gọi là "tiêu chuẩn đề xuất", nó không có nghĩa gì khác ngoài một đề xuất. Nếu bạn muốn tranh luận rằng một tiêu chuẩn đề xuất có thể được sử dụng. Đó chính xác là những gì tôi đã viết.
Loïc Faure-Lacroix

102

Tôi đã dành vài giờ với google và tìm thấy câu trả lời ở đây

PUT => Nếu người dùng có thể cập nhật tất cả hoặc chỉ một phần của bản ghi , hãy sử dụng PUT (người dùng kiểm soát những gì được cập nhật)

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

PATCH => Nếu người dùng chỉ có thể cập nhật một bản ghi một phần , chỉ cần nói một địa chỉ email (ứng dụng kiểm soát những gì có thể được cập nhật), hãy sử dụng PATCH.

PATCH /users/123
[description of changes]

Tại sao Patch

PUTphương pháp cần thêm băng thông hoặc xử lý toàn bộ tài nguyên thay vì một phần. Vì vậy, PATCHđã được giới thiệu để giảm băng thông.

Giải thích về VÒI

PATCH là một phương pháp không an toàn, cũng không bình thường và cho phép cập nhật đầy đủ và một phần và các tác dụng phụ trên các tài nguyên khác.

PATCH là một phương thức mà thực thể kèm theo chứa một tập hợp các hướng dẫn mô tả cách một tài nguyên hiện đang cư trú trên máy chủ gốc nên được sửa đổi để tạo ra một phiên bản mới.

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

Ở đây thêm thông tin về đặt và vá


7
Tại sao cái này không an toàn?
Bishisht Bhatta

1
PATCHtrong số POST, PUTv.v. không "an toàn", vì nó sửa đổi dữ liệu của bạn (có tác dụng phụ). So với GET, OPTIONSvv (phương pháp an toàn) nơi bạn có thể gọi các điểm cuối nhiều lần mà không có bất kỳ tác dụng phụ nào.
emix

1
PATCH KHÔNG được giới thiệu để chỉ lưu bandwith. Như RFC 5789 tuyên bố:> "Một phương pháp mới là cần thiết để cải thiện khả năng tương tác và ngăn ngừa lỗi." Trong môi trường đa song song, chỉ có các PUT bao gồm phần còn lại của tải trọng sẽ làm tăng nguy cơ sửa đổi các thuộc tính khác của tài nguyên. PATCH giải quyết vấn đề như vậy.
Tomasz Nazar

43

Đặt
nếu tôi muốn thay đổi firsttên của mình sau đó gửi yêu cầu đặt để cập nhật

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

nhưng ở đây có một vấn đề là putyêu cầu khi tôi muốn gửi putyêu cầu tôi phải gửi tất cả hai tham số đó firstlast
do đó bắt buộc phải gửi lại tất cả giá trị

:
patchyêu cầu nói. chỉ gửi cái datamà bạn muốn updatevà nó sẽ không ảnh hưởng hoặc thay đổi dữ liệu khác.
vì vậy không cần phải gửi lại tất cả giá trị chỉ cần tôi muốn cập nhật tên của mình vì vậy tôi chỉ cần gửi firsttên để cập nhật.


13

Dưới đây là sự khác biệt giữa các phương thức POST, PUT và PATCH của giao thức HTTP.

BÀI ĐĂNG

Phương thức HTTP.POST luôn tạo một tài nguyên mới trên máy chủ. Đó là một yêu cầu không bình thường, tức là nếu người dùng đạt được cùng một yêu cầu 2 lần thì nó sẽ tạo ra một tài nguyên mới khác nếu không có ràng buộc nào.

Phương thức bài http giống như một truy vấn INSERT trong SQL, luôn tạo một bản ghi mới trong cơ sở dữ liệu.

Ví dụ: Sử dụng phương thức POST để lưu người dùng mới, đặt hàng, vv trong đó máy chủ phụ trợ quyết định id tài nguyên cho tài nguyên mới.

ĐẶT

Trong phương thức HTTP.PUT, tài nguyên được xác định đầu tiên từ URL và nếu nó tồn tại thì nó được cập nhật nếu không tài nguyên mới được tạo. Khi tài nguyên đích tồn tại, nó sẽ ghi đè lên tài nguyên đó với một cơ thể hoàn toàn mới. Đó là phương thức HTTP.PUT được sử dụng để TẠO hoặc CẬP NHẬT tài nguyên.

Phương thức http put giống như một truy vấn MERGE trong SQL để chèn hoặc cập nhật một bản ghi tùy thuộc vào việc bản ghi đã cho có tồn tại hay không.

Yêu cầu PUT là idempotent tức là nhấn hai yêu cầu tương tự hai lần sẽ cập nhật bản ghi hiện tại (Không có bản ghi mới nào được tạo). Trong phương thức PUT, id tài nguyên được quyết định bởi máy khách và được cung cấp trong url yêu cầu.

Ví dụ: Sử dụng phương pháp PUT để cập nhật người dùng hoặc đơn hàng hiện có.

Phương thức HTTP.PATCH được sử dụng để sửa đổi một phần tài nguyên tức là cập nhật delta.

Phương pháp vá http giống như một truy vấn CẬP NHẬT trong SQL chỉ thiết lập hoặc cập nhật các cột được chọn chứ không phải toàn bộ hàng.

Ví dụ: Bạn có thể sử dụng phương thức PATCH để cập nhật trạng thái đơn hàng.

VÒI / api / người dùng / 40450236 / đơn hàng / 10234557

Thân yêu cầu: {status: 'Đã giao'}


Đây là lời giải thích tồi tệ nhất mà bất cứ ai cũng có thể đọc về đặt và vá. Và bên cạnh đó, sau rất nhiều câu trả lời hay được đăng, điều gì khiến bạn nghĩ câu trả lời của bạn khác ở đây?
CodeHunter

3

Có những hạn chế trong PUT so với PATCH trong khi thực hiện cập nhật. Sử dụng PUT yêu cầu chúng tôi chỉ định tất cả các thuộc tính ngay cả khi chúng tôi chỉ muốn thay đổi một thuộc tính. Nhưng nếu chúng ta sử dụng phương thức PATCH, chúng ta chỉ có thể cập nhật các trường chúng ta cần và không cần phải đề cập đến tất cả các trường. PATCH không cho phép chúng tôi sửa đổi một giá trị trong một mảng hoặc loại bỏ một thuộc tính hoặc mục nhập mảng.


1

Các phương pháp PUTPATCH có bản chất tương tự nhau, nhưng có một sự khác biệt chính.

PUT - trong yêu cầu PUT , thực thể kèm theo sẽ được coi là phiên bản sửa đổi của tài nguyên cư trú trên máy chủ và nó sẽ được thay thế bởi thực thể được sửa đổi này.

PATCH - trong yêu cầu PATCH , thực thể kèm theo chứa tập hợp các hướng dẫn về cách thực thể cư trú trên máy chủ, sẽ được sửa đổi để tạo phiên bản mới hơn.


1

Theo các điều khoản HTTP, PUTYêu cầu này giống như một câu lệnh cập nhật cơ sở dữ liệu. PUT- được sử dụng để sửa đổi tài nguyên hiện có (POSTED trước đó). Mặt khác, PATCHyêu cầu được sử dụng để cập nhật một phần tài nguyên hiện có.

Ví dụ:

Chi tiết khách hàng:

// This is just a example.

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

Khi chúng tôi muốn cập nhật lên toàn bộ hồ sơ? chúng ta phải sử dụng Http PUT verbcho điều đó.

nhu la:

// Customer Details Updated.

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

Mặt khác, nếu chúng tôi chỉ muốn cập nhật phần của bản ghi chứ không phải toàn bộ bản ghi thì hãy tiếp tục Http PATCH verb. nhu la:

   // Only Customer firstName and lastName is Updated.

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

PUT VS POST:

Khi sử dụng PUTyêu cầu, chúng tôi phải gửi tất cả các tham số như FirstName, lastName, email, phoneNumber Trong khi patchyêu cầu chỉ gửi các tham số mà chúng tôi muốn cập nhật và nó sẽ không ảnh hưởng hoặc thay đổi dữ liệu khác.

Để biết thêm chi tiết, vui lòng truy cập: https://fullstack-developer.academy/restful-api-design-post-vs-put-vs-patch/


0

Phương pháp đặt và Patch là tương tự nhau. Nhưng trong đường ray, nó có metod khác nhau Nếu chúng ta muốn cập nhật / thay thế toàn bộ bản ghi thì chúng ta phải sử dụng phương thức Put. Nếu chúng tôi muốn cập nhật bản ghi cụ thể, hãy sử dụng phương pháp Patch.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.