Xu Hướng 10/2023 # Sự Khác Biệt Giữa Put, Post Và Patch Là Gì? # Top 11 Xem Nhiều

Bạn đang xem bài viết Sự Khác Biệt Giữa Put, Post Và Patch Là Gì? được cập nhật mới nhất tháng 10 năm 2023 trên website Channuoithuy.edu.vn. Hy vọng những thông tin mà chúng tôi đã chia sẻ là hữu ích với bạn. Nếu nội dung hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất.

VĂN BẢN: Gửi một sửa đổi một phần cho tài nguyên. Nếu bạn chỉ cần cập nhật một trường cho tài nguyên, bạn có thể muốn sử dụng phương thức PATCH.

Lưu ý: Vì POST, PUT, DELETE sửa đổi nội dung, các bài kiểm tra với Fiddler cho url bên dưới chỉ bắt chước các cập nhật. Nó không xóa hoặc sửa đổi thực sự. Chúng ta chỉ có thể xem các mã trạng thái để kiểm tra xem có chèn thêm, cập nhật, xóa hay không.

URL: http://jsonplaceholder.typicode.com/posts/

1) NHẬN:

GET là loại phương thức yêu cầu HTTP đơn giản nhất; một trình duyệt sử dụng mỗi khi bạn nhấp vào liên kết hoặc nhập URL vào thanh địa chỉ. Nó ra lệnh cho máy chủ truyền dữ liệu được xác định bởi URL đến máy khách. Dữ liệu không bao giờ được sửa đổi ở phía máy chủ do yêu cầu GET. Theo nghĩa này, một yêu cầu GET là chỉ đọc.

Kiểm tra với Fiddler hoặc PostMan: Chúng tôi có thể sử dụng Fiddler để kiểm tra phản hồi. Mở Fiddler và chọn tab Soạn. Chỉ định động từ và url như hiển thị bên dưới và nhấp vào Thực thi để kiểm tra phản hồi.

Động từ: NHẬN

url: http://jsonplaceholder.typicode.com/posts/

Phản hồi: Bạn sẽ nhận được phản hồi như:

“userId”: 1, “id”: 1, “title”: “sunt aut …”, “cơ thể”: “quia et suscipit …”

Trong đường dẫn của Happy Happy (hoặc không có lỗi), GET trả về một đại diện bằng XML hoặc JSON và mã phản hồi HTTP là 200 (OK). Trong trường hợp lỗi, nó thường trả về 404 (KHÔNG TÌM KIẾM) hoặc 400 (BẮT BUỘC YÊU CẦU).

2) BÀI:

Động từ POST chủ yếu được sử dụng để tạo tài nguyên mới. Cụ thể, nó được sử dụng để tạo tài nguyên cấp dưới. Đó là, phụ thuộc vào một số tài nguyên (ví dụ: cha mẹ) khác.

Khi tạo thành công, trả về trạng thái HTTP 201, trả về tiêu đề Vị trí có liên kết đến tài nguyên mới được tạo với trạng thái HTTP 201.

Động từ: POST

url: http://jsonplaceholder.typicode.com/posts/

Cơ quan yêu cầu:

dữ liệu: {title: ‘foo’, body: ‘bar’, userId: 1000, Id: 1000}

Phản hồi: Bạn sẽ nhận được mã phản hồi là 201.

Nếu chúng tôi muốn kiểm tra bản ghi được chèn với Id = 1000, hãy thay đổi động từ thành Nhận và sử dụng cùng một url và nhấp vào Thực thi.

Như đã nói trước đó, url trên chỉ cho phép đọc (GET), chúng tôi không thể đọc dữ liệu cập nhật trong thực tế.

3) PUT:

PUT thường được sử dụng cho các khả năng cập nhật , PUT-ing đến một URI tài nguyên đã biết với phần thân yêu cầu có chứa đại diện mới được cập nhật của tài nguyên ban đầu.

Động từ: PUT

url: http://jsonplaceholder.typicode.com/posts/1

Cơ quan yêu cầu:

dữ liệu: {title: ‘foo’, body: ‘bar’, userId: 1, Id: 1}

Trả lời: Khi cập nhật thành công, nó trả về 200 (hoặc 204 nếu không trả lại bất kỳ nội dung nào trong phần thân) từ PUT.

4) XÓA:

XÓA là khá dễ hiểu. Nó được sử dụng để xóa tài nguyên được xác định bởi URI.

Khi xóa thành công, trả về trạng thái HTTP 200 (OK) cùng với phần thân phản hồi, có thể là biểu diễn của mục đã xóa (thường yêu cầu quá nhiều băng thông) hoặc phản hồi được bao bọc (xem Giá trị trả về bên dưới). Hoặc là hoặc trả về trạng thái HTTP 204 (KHÔNG CÓ NỘI DUNG) mà không có phần phản hồi. Nói cách khác, trạng thái 204 không có phần thân hoặc phản hồi kiểu JSEND và trạng thái HTTP 200 là các phản hồi được đề xuất.

Động từ: XÓA

url: http://jsonplaceholder.typicode.com/posts/1

Trả lời: Khi xóa thành công, nó trả về trạng thái HTTP 200 (OK) cùng với phần thân phản hồi.

Ví dụ giữa PUT và PATCH

ĐẶT

Nếu tôi phải thay đổi tên của mình thì hãy gửi yêu cầu PUT để cập nhật:

{“First”: “Nazmul”, “last”: “hasan”} Vì vậy, ở đây để cập nhật tên đầu tiên, chúng tôi cần gửi lại tất cả các tham số của dữ liệu.

VÁ:

Yêu cầu vá nói rằng chúng tôi sẽ chỉ gửi dữ liệu mà chúng tôi cần sửa đổi mà không sửa đổi hoặc ảnh hưởng đến các phần khác của dữ liệu. Ví dụ: nếu chúng tôi chỉ cần cập nhật tên đầu tiên, chúng tôi chỉ chuyển tên đầu tiên.

https://jsonplaceholder.typicode.com/ https://github.com/typicode/jsonplaceholder#how-to Sự khác biệt chính giữa yêu cầu PATCH và PUT là gì? http://www.restapitutorial.com/lessons/httpmethods.html

Sự Khác Biệt Chính Giữa Yêu Cầu Patch Và Put Là Gì?

Độ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.

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

Phương thức PATCH yêu cầu một tập hợp các thay đổi được mô tả trong thực thể yêu cầu được áp dụng cho tài nguyên được xác định bởi URI yêu cầu. 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ủ MAY 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 logic tài nguyên null không ) và quyền, v.v.

Sự khác biệt giữa các yêu cầu PUT và PATCH đượ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ủ Origin và máy khách đang yêu cầu thay thế phiên bản đã lưu trữ. Với PATCH, tuy nhiên, 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ủ Origin nên được sửa đổi thành tạo một phiên bản mới. Phương thức PATCH ảnh hưởng đến tài nguyên được xác định bởi URI yêu cầu và nó cũng MAY có tác dụng phụ đối với các tài nguyên khác; tức là, tài nguyên mới có thể được tạo hoặc tài nguyên hiện có được sửa đổi bằng ứng dụng của một PATCH.

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 thì động từ vá RFC nên được sử dụng để 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.

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.

Phân Biệt Sự Khác Nhau Giữa Post Và Put

Trong một bài viết trước đây chúng ta đã được tìm hiểu sự khác biệt giữa POST và GET. Ngoài GET và POST thì PUT cũng là một HTTP Method được sử dụng khá thường xuyên trong các ứng dụng web hướng theo kiến trúc RESTful API. Có nhiều ban không phân biệt được sự khác nhau giữa hai method này và một số nghĩ rằng chúng giống nhau trong khi đó một số thì chỉ sử dụng POST mà không biết sự tồn tại của PUT, phần lớn thì lại cho rằng POST chỉ có thể được dùng để tạo mới resource còn PUT thì để cập nhật .

Nên Sử Dụng POST Để Tạo Mới Resource

Chúng ta nên sử dụng HTTP POST method để tạo mới resource. Ví dụ để tạo mới một câu hỏi trên chúng tôi chúng ta sẽ thường sử dụng kết hợp URL và HTTP method như sau:

POST /questions HTTP/1.1 Host: www.codehub.vn/ POST /questions/101 HTTP/1.1 Host: www.codehub.vn/

Mặc dù vậy thì cách sử dụng POST để cập nhật resource như trên ít được sử dụng.

Nên Sử Dụng PUT Để Cập Nhật Resource Có Sẵn

Chúng ta nên sử dụng HTTP PUT method để tạo mới resource. Ví dụ để cập nhật một câu hỏi trên chúng tôi với ID là 101 chúng ta sẽ thường sử dụng kết hợp URL và HTTP method như sau:

PUT /questions/101 HTTP/1.1 Host: www.codehub.vn/

PUT cũng có thể được sử dụng để tạo mới một resource. Ví dụ để tạo mới một câu hỏi trên chúng tôi thì ngoài cách sử dụng POST method như đã tìm hiểu ở trên thì bạn có thể sử dụng kết hợp URL và PUT HTTP method như sau:

PUT /questions/new HTTP/1.1 Host: www.codehub.vn/

Mặc dù vậy thì cách sử dụng POST để cập nhật resource như trên ít được sử dụng.

Kết Luận

Mặc dù bạn có thể không cần phải tuân theo RESTful API hoặc sử dụng các HTTP method tuỳ ý theo các cách khác nhau tuy nhiên sử dụng một tiêu chuẩn thống nhất sẽ giúp bạn dễ dàng quản lý thay đổi cũng như mở rộng ứng dụng. Ngoài ra khi có các developer mới tham gia vào dự án họ sẽ có thể dễ dàng nắm bắt được cách dự án được phát triển như thế nào.

Sự Khác Biệt Giữa Các Yêu Cầu Put Và Patch Trong Http Là Gì?

Khoảng 20 năm.

PUT ban đầu được thêm vào thông số HTTP / 1.1 vào năm 1997. Nó được dự định là một thay thế cho POST cho tệp được tải lên, nhưng nó đã bị bỏ qua trong vài năm cho đến khi cuối cùng các máy chủ web bắt đầu thực hiện nó với hành vi giống hệt với POST. Các yêu cầu kéo (nếu một thứ như vậy thực sự tồn tại trở lại thì trông như thế này

/ * triển khai HTTP PUT * / if (request.method == chúng tôi {bài đăng cuộc gọi (request); }

Cuối cùng, những người không bao giờ đọc thông số kỹ thuật, nhưng muốn phát âm thông minh bắt đầu đề nghị mọi người sử dụng put () nhưng có thể vì tiếng Anh không phải là ngôn ngữ đầu tiên của họ, họ không biết sự khác biệt tinh tế giữa hai từ, vì vậy họ đã quyết định rằng PUT nên được sử dụng để cập nhật tài nguyên động (vì thông số kỹ thuật cho biết tất cả các trường sẽ được gửi) và điều đó khiến POST không có gì để làm, vì vậy ai đó đã quyết định rằng nó nên được sử dụng để tạo ra những thứ mà bạn biết, như blog Đăng bài.

Từ RFC 2616 Mục 9.6

Phương thức PUT yêu cầu thực thể kèm theo được lưu trữ theo URI yêu cầu được cung cấp. Nếu URI yêu cầu đề cập đến một tài nguyên đã tồn tại, thực thể kèm theo NÊN được coi là phiên bản sửa đổi của tài nguyên cư trú trên máy chủ gốc

Giáo dục

Sự khác biệt cơ bản giữa các yêu cầu POST và PUT được phản ánh theo nghĩa khác nhau của URI yêu cầu. Tài nguyên đó có thể là một quá trình chấp nhận dữ liệu, một cổng vào một số giao thức khác hoặc một thực thể riêng biệt chấp nhận các chú thích. Ngược lại, URI trong yêu cầu PUT xác định thực thể kèm theo yêu cầu – tác nhân người dùng biết URI được dự định là gì và máy chủ KHÔNG cố gắng áp dụng yêu cầu cho một số tài nguyên khác. Nếu máy chủ mong muốn rằng yêu cầu được áp dụng cho một URI khác,

Các thực thể kèm theo yêu cầu có nghĩa là một tập tin.

PATCH ban đầu được đề xuất vào năm 2010 trong RFC 5789

https://tools.ietf.org/html/rfc5789

Tôi không có ý tưởng khi nó được thực hiện lần đầu tiên. Và nó chắc chắn chưa bao giờ được áp dụng rộng rãi. Nghe có vẻ như ban đầu nó có nghĩa là để cung cấp khác biệt hoặc thay đổi, nhưng vì PUT đã hoàn toàn bị nhầm lẫn với POST, nên điều đó là vô vọng.

Vì vậy, câu trả lời ngắn gọn là sử dụng POST cho hầu hết các yêu cầu web.

Câu trả lời dài hơn một chút là PUT PUT có nghĩa là để tải lên các tệp (đó là những gì mà thực thể kèm theo với yêu cầu có nghĩa là) và PATCH có nghĩa là để cập nhật các tệp … bạn biết, như với một BCHNG.

Sử dụng phổ biến là sử dụng bất cứ điều gì làm cho bạn cảm thấy tốt.

What Is The Difference Between Put, Post And Patch?

Difference between PUT, POST, GET, DELETE and PATCH IN HTTP Verbs:

The most commonly used HTTP verbs POST, GET, PUT, DELETE are similar to CRUD (Create, Read, Update and Delete) operations in database. We specify these HTTP verbs in the capital case. So, the below is the comparison between them.

create – POST

read – GET

update – PUT

delete – DELETE

PATCH: Submits a partial modification to a resource. If you only need to update one field for the resource, you may want to use the PATCH method.

Note: Since POST, PUT, DELETE modifies the content, the tests with Fiddler for the below url just mimicks the updations. It doesn’t delete or modify actually. We can just see the status codes to check whether insertions, updations, deletions occur.

URL: http://jsonplaceholder.typicode.com/posts/

1) GET:

Checking with Fiddler or PostMan: We can use Fiddler for checking the response. Open Fiddler and select the Compose tab.

Verb: GET

url: http://jsonplaceholder.typicode.com/posts/

Response: You will get the response as:

“userId”: 1, “id”: 1, “title”: “sunt aut…”, “body”: “quia et suscipit…”

In the “happy” (or non-error) path, GET returns a representation in XML or JSON and an HTTP response code of 200 (OK). In an error case, it most often returns a 404 (NOT FOUND) or 400 (BAD REQUEST).

2) POST:

The POST verb is mostly utilized to create new resources. In particular, it’s used to create subordinate resources. That is, subordinate to some other (e.g. parent) resource.

On successful creation, return HTTP status 201, returning a Location header with a link to the newly-created resource with the 201 HTTP status.

Checking with Fiddler or PostMan: We can use Fiddler for checking the response. Open Fiddler and select the Compose tab.

Verb: POST

url: http://jsonplaceholder.typicode.com/posts/

Request Body:

data: { title: ‘foo’, body: ‘bar’, userId: 1000, Id : 1000 }

Response: You would receive the response code as 201.

3) PUT:

PUT is most-often utilized for update capabilities, PUT-ing to a known resource URI with the request body containing the newly-updated representation of the original resource.

Checking with Fiddler or PostMan: We can use Fiddler for checking the response. Open Fiddler and select the Compose tab.

Verb: PUT

url: http://jsonplaceholder.typicode.com/posts/1

Request Body:

data: { title: ‘foo’, body: ‘bar’, userId: 1, Id : 1 }

Response: On successful update it returns 200 (or 204 if not returning any content in the body) from a PUT.

4) DELETE:

DELETE is pretty easy to understand. It is used to delete a resource identified by a URI.

On successful deletion, return HTTP status 200 (OK) along with a response body, perhaps the representation of the deleted item (often demands too much bandwidth), or a wrapped response (see Return Values below). Either that or return HTTP status 204 (NO CONTENT) with no response body. In other words, a 204 status with no body, or the JSEND-style response and HTTP status 200 are the recommended responses.

Checking with Fiddler or PostMan: We can use Fiddler for checking the response. Open Fiddler and select the Compose tab.

Verb: DELETE

url: http://jsonplaceholder.typicode.com/posts/1

Response: On successful deletion it returns HTTP status 200 (OK) along with a response body.

Example between PUT and PATCH

PUT

If I had to change my firstname then send PUT request for Update:

{ “first”: “Nazmul”, “last”: “hasan” } So, here in order to update the first name we need to send all the parameters of the data again.

PATCH:

Patch request says that we would only send the data that we need to modify without modifying or effecting other parts of the data. Ex: if we need to update only the first name, we pass only the first name.

Please refer the below links for more information:

https://jsonplaceholder.typicode.com/

https://github.com/typicode/jsonplaceholder#how-to

What is the main difference between PATCH and PUT request?

http://www.restapitutorial.com/lessons/httpmethods.html

Put Vs Patch (What’S The Difference?)

PUT vs PATCH

When learning web development and HTTP specification, it is not unlikely to find yourself getting confused about the type of verb to use, and when to use it. With most applications on the internet being CRUD (create, read/retrieve, updates, delete), developers must learn how to match HTTP verbs to these actions. Typically, the verbs and actions are matched as follows:

POST – Create

GET – Read/Retrieve

PUT/PATCH – Update

DELETE – Delete

From this mapping, it is not surprising that most people think that PUT and PATCH are allies that do the same thing. However, the reality is far more complex, especially when it comes to overlapping functionality and other complications. Actually, PUT and PATCH might be doing the same thing of updating a resource at a location, but they do it differently. Therefore, to understand more about these verbs, let’s dive deep into HTTP specification and identify the subtle differences between the two.

Browse the Best Free APIs List

What is PUT?

PUT is a method of modifying resource where the client sends data that updates the entire resource. It is used to set an entity’s information completely. PUT is similar to POST in that it can create resources, but it does so when there is a defined URI. PUT overwrites the entire entity if it already exists, and creates a new resource if it doesn’t exist.

For example, when you want to change the first name of a person in a database, you need to send the entire resource when making a PUT request.

{“first": "John", "last": "Stone”}

To make a PUT request, you need to send the two parameters; the first and the last name.

What is PATCH?

Unlike PUT, PATCH applies a partial update to the resource.

This means that you are only required to send the data that you want to update, and it won’t affect or change anything else. So if you want to update the first name on a database, you will only be required to send the first parameter; the first name.

Differentiating PUT and PATCH Using an Analogy of Land

Imagine we have empty a piece of land where we have the option to erect multiple houses. The land is divided into plots and houses will be built on each plot as designated by numbers. All we need it to do is to determine which house will be built where. When we translate the above information to REST, we will have the following: https://domain.com/house

PUT

Let say plot 1 has a house that has been equipped with all the amenities. Making a PUT request can lead to a number of outcomes. However, to stick to the topic, let’s consider the following request: https://domain.com/house/1 using this payload:

{ "front_patio": true, "back_patio": true, "windows": 12, "doors": 4, "Balcony": false }

Now that we have a house on plot 1, what will happen is that every property on the house will be replaced by the data in the payload. So, if our payload only had the following information:

{ "doors": 5 }

We will have a house that has doors property and nothing else since a PUT request overwrites everything.

What if we issue a PUT request on a resource that doesn’t exist. In this case let’s say on plot 3: https://domain.com/house/3. In this case, a new resource will be created. But it is crucial to note that, it is imperative to define the entire resource when making PUT requests or else it could yield undesired results.

PATCH

PATCH is used when you want to apply a partial update to the resource. Let’s assume the house on plot 1 has the following features:

{ "front_patio": true, "back_patio": true, "windows": 12, "doors": 4, "Balcony": false }

And we want to make the following update:

{ "doors": 5 }

The result will be as follows:

{ "front_patio": true, "back_patio": true, "windows": 12, "doors": 5, "Balcony": false }

Additionally, we can also add a new feature that didn’t exist in the resource. For example, a garage and the result will be:

{ "front_patio": true, "back_patio": true, "windows": 12, "doors": 5, "Balcony": false, “garage”: true }

However, you should note that calling HTTP PATCH on a resource that doesn’t exist is bound to fail and no resource will be created.

A Summary of Differences/Similarities between PUT and PATCH

From the discussion above, we can clearly outline the similarities/ differences between these two methods.

Similarities between PUT and PATCH

The only similarity between the two is that they can both be used to update resources in a given location.

Differences between PUT and PATCH

The main difference between PUT and PATCH requests is witnessed in the way the server processes the enclosed entity to update the resource identified by the Request-URI. When making a PUT request, the enclosed entity is viewed as the modified version of the resource saved on the original server, and the client is requesting to replace it. However, with PATCH, the enclosed entity boasts a set of instructions that describe how a resource stored on the original server should be partially modified to create a new version.

The second difference is when it comes to idempotency. HTTP PUT is said to be idempotent since it always yields the same results every after making several requests. On the other hand, HTTP PATCH is basically said to be non-idempotent. However, it can be made to be idempotent based on where it is implemented.

Final Verdict

Now that you have a clear outlook of the similarities/differences between PUT and PATCH, you will probably make the best choice when designing a RESTful API or a new web application. Understanding these subtle differences will help improve your experience when integrating and creating cooperative apps.