Trong thiết kế API RESTful, PUT và PATCH là hai phương thức HTTP được sử dụng để cập nhật tài nguyên trên máy chủ, nhưng sự khác biệt giữa PUT và PATCH trong API REST là ở cách chúng thực hiện cập nhật và các tình huống trong đó mỗi phương thức phù hợp nhất. Cả hai phương pháp đều được thiết kế để sửa đổi dữ liệu hiện có, nhưng hiểu được sự khác biệt giữa PUT và PATCH trong API REST có thể giúp nhà phát triển đưa ra lựa chọn tốt nhất dựa trên tính chất của bản cập nhật mà họ cần thực hiện. Trong bài đăng trên blog này, chúng ta sẽ khám phá sự khác biệt giữa PUT và PATCH trong API REST, tập trung vào cuộc tranh luận PATCH và cập nhật REST, thời điểm sử dụng từng loại và cung cấp hướng dẫn về cách chọn phương pháp phù hợp cho các trường hợp sử dụng khác nhau.
PUT trong API REST là gì?
Để hiểu sự khác biệt giữa PUT và PATCH trong API REST, trước tiên, chúng ta cần biết PUT là gì ngay từ đầu. Dựa trên Mục 9.6 RFC 2616, phương thức PUT trong REST API 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ì thực thể kèm theo NÊN được coi là phiên bản sửa đổi của thực thể nằm trên máy chủ gốc. Nếu URI yêu cầu không trỏ đến tài nguyên hiện có và URI đó có thể được tác nhân người dùng yêu cầu xác định là tài nguyên mới thì máy chủ gốc có thể tạo tài nguyên bằng URI đó.
Nói cách khác, phương thức PUT được sử dụng để cập nhật toàn bộ tài nguyên trên máy chủ. Điều này làm cho PUT trở thành một bản cập nhật “hoàn chỉnh” hơn, thường được sử dụng khi cần thay thế toàn bộ tài nguyên.
Vì vậy, PUT là tốt nhất cho các trường hợp sử dụng sau:
- Cập nhật tài nguyên hoàn chỉnh (ví dụ: cập nhật hồ sơ người dùng với tất cả thông tin mới).
- Thay thế toàn bộ một mục hoặc bản ghi.
- Khi danh tính của tài nguyên rõ ràng và dữ liệu của tài nguyên đó cần được làm mới hoàn toàn.
Trong các hệ thống như Elaticsearch, các hoạt động bình thường là cần thiết để đảm bảo tính nhất quán của dữ liệu. Ví dụ: cập nhật một tài liệu trong Elaticsearch bằng PUT đảm bảo rằng cùng một yêu cầu có thể được lặp lại mà không có tác dụng phụ ngoài ý muốn.
PATCH trong API REST là gì?
Bây giờ chúng ta đã đề cập đến PUT trong REST API, hãy cùng xem PATCH là gì trong REST API và cách nó hoạt động trước khi so sánh PUT với PATCH trong REST API. Như được định nghĩa trong RFC 5789, phương thức PATCH trong REST API yêu cầu áp dụng một tập hợp các thay đổi được mô tả trong thực thể yêu cầu cho tài nguyên được xác định bởi URI yêu cầu.
Điều này phù hợp với sự khác biệt giữa API PUT và PATCH REST, trong đó bạn chỉ gửi dữ liệu cần sửa đổi và máy chủ áp dụng những thay đổi đó cho tài nguyên hiện có mà không thay đổi toàn bộ tài nguyên. Các nhà phát triển thường tạo các bản vá để thể hiện những thay đổi gia tăng này, đảm bảo truyền dữ liệu tối thiểu và cập nhật hiệu quả.
Đó là lý do tại sao phương thức PATCH trong REST API phù hợp hơn với các trường hợp sử dụng sau:
- Chỉ cập nhật một tập hợp con các trường trong tài nguyên (ví dụ: thay đổi địa chỉ email hoặc số điện thoại của người dùng). Ví dụ về API PATCH có thể liên quan đến việc chỉ gửi email mới, giữ nguyên các trường khác.
- Cải thiện hiệu suất bằng cách giảm thiểu tải trọng dữ liệu.
- Khi bạn muốn cập nhật tài nguyên tăng dần thay vì thay thế hoàn toàn.
- Tạo các bản vá để gói gọn các thay đổi của trường cụ thể, như sửa đổi email của người dùng mà không ảnh hưởng đến dữ liệu không liên quan.
Đối với các nền tảng như CMS không đầu thường xử lý các cấu trúc nội dung phức tạp, sử dụng PATCH cho các bản cập nhật nhỏ hơn—như sửa đổi một trường đơn lẻ—có thể giảm tải máy chủ và cải thiện hiệu suất.
Với hai phương pháp này, bạn sẽ có ý tưởng rõ ràng về PUT và PATCH trong REST API. Tuy nhiên, trước khi đi vào sự khác biệt giữa PUT và PATCH trong REST API, chúng ta cần nói về Idempotence trong hai phương thức này.
Sự bất lực trong PUT Vs Patch trong API REST
Trong API REST, tính bình thường đề cập đến thuộc tính của một thao tác mà khi lặp lại nhiều lần với cùng một dữ liệu đầu vào sẽ dẫn đến cùng một kết quả. Điều này có nghĩa là việc thực hiện cùng một yêu cầu nhiều lần sẽ có tác dụng tương tự trên máy chủ, bất kể nó được thực thi bao nhiêu lần. Điều này rất quan trọng để đảm bảo tính ổn định và khả năng dự đoán trong API. Nhưng nó có liên quan như thế nào đến sự khác biệt giữa PUT và PATCH trong REST API?
Phương pháp PUT và tính bình đẳng
Phương thức PUT trong REST API luôn bình thường vì nó được thiết kế để thay thế toàn bộ tài nguyên tại một URI được chỉ định bằng dữ liệu được cung cấp trong yêu cầu. Nói cách khác, nếu bạn thực hiện yêu cầu PUT nhiều lần với cùng một dữ liệu tài nguyên thì kết quả sẽ luôn giống nhau.
Tại sao PUT bình thường? Khi bạn thực hiện một yêu cầu PUT, về cơ bản bạn đang thông báo cho máy chủ rằng “Đây là trạng thái đầy đủ và chính xác mà tôi muốn đối với tài nguyên này”. Cho dù bạn đưa ra yêu cầu PUT một lần hay nhiều lần, tài nguyên kết quả sẽ luôn giống hệt nhau.
Ví dụ: hãy xem xét trường hợp bạn cập nhật địa chỉ email của người dùng. Nếu bạn thực hiện cùng một yêu cầu PUT nhiều lần, kết quả sẽ không bị thay đổi vì tài nguyên luôn được thay thế bằng cùng một dữ liệu.
Ví dụ:
| PUT /users/1{“tên người dùng”: “john_doe”,”email”: “[email protected]”} |
Nếu bạn gửi yêu cầu này nhiều lần thì kết quả sẽ luôn giống nhau:
| {“tên người dùng”: “john_doe”,”email”: “[email protected]”} |
Ngay cả khi dữ liệu của người dùng đã như vậy thì việc gửi lại yêu cầu cũng không thay đổi được gì. Nó thay thế dữ liệu bằng cùng một dữ liệu, do đó hiệu ứng của yêu cầu vẫn giữ nguyên bất kể nó được lặp lại bao nhiêu lần. Đây là những gì làm cho PUT bình thường.
Phương pháp PATCH và sự bất lực
Mặt khác, phương thức PATCH trong REST API nhìn chung cũng bình thường nhưng linh hoạt hơn. Khi bạn tạo các bản vá, hãy đảm bảo các thao tác đều bình thường (ví dụ: đặt giá trị) để tránh các tác dụng phụ ngoài ý muốn do các yêu cầu lặp lại. Việc PATCH có bình thường hay không phụ thuộc vào hoạt động và dữ liệu được sửa đổi.
Tại sao PATCH lại bất lực? Đối với các yêu cầu PATCH, idempotence có nghĩa là việc áp dụng cùng một bản vá nhiều lần sẽ có cùng một kết quả. Điều này đúng miễn là bản thân miếng dán không gây ra thêm tác dụng phụ hoặc thay đổi nào khi áp dụng nhiều lần. Nếu bạn tiếp tục áp dụng cùng một bản vá với cùng một dữ liệu, kết quả sẽ không thay đổi sau lần áp dụng đầu tiên.
Ví dụ: nếu bạn chỉ cập nhật email của người dùng, việc gửi đi gửi lại cùng một yêu cầu PATCH sẽ không thay đổi kết quả sau lần đầu tiên, ngay cả khi yêu cầu được thực hiện nhiều lần. Email của người dùng sẽ giữ nguyên và trạng thái của tài nguyên sẽ không thay đổi.
Ví dụ về API PATCH:
| PATCH /users/1{“email”: “[email protected]”} |
Nếu email đã là [email protected] thì việc áp dụng lại PATCH này sẽ không dẫn đến thay đổi nào, khiến nó trở nên bình thường.
Tuy nhiên, PATCH cũng có thể không bình thường trong một số trường hợp. Ví dụ: nếu thao tác PATCH sửa đổi bộ đếm hoặc thêm các mục vào danh sách (chẳng hạn như tăng số hoặc thêm vào một mảng), các ứng dụng lặp lại của cùng một PATCH có thể dẫn đến các kết quả khác nhau. Điều này sẽ vi phạm tính chất bất lực.
Ví dụ về REST PATCH API không bình thường:
| PATCH /counter/1{“tăng”: 1} |
Nếu bạn áp dụng PATCH này nhiều lần, bộ đếm sẽ tiếp tục tăng, dẫn đến các giá trị khác nhau mỗi lần. Điều này không bình thường vì kết quả thay đổi theo từng ứng dụng.
Bây giờ bạn đã biết những điều cơ bản, chúng ta có thể xem xét một số tình huống ví dụ để hiểu rõ hơn về sự khác biệt giữa PUT và PATCH trong API REST.
Tình huống ví dụ: PUT và PATCH trong API REST
Bỏ lý thuyết sang một bên, chúng ta hãy xem xét sự khác biệt giữa PUT và PATCH bằng các ví dụ, bao gồm cả hoạt động bình thường và không bình thường.
Kịch bản 1: Yêu cầu PUT - Thay thế toàn bộ tài nguyên
Hãy tưởng tượng một điểm cuối API để quản lý sản phẩm trong hệ thống thương mại điện tử. Bạn cần cập nhật tất cả thông tin chi tiết của sản phẩm, bao gồm tên, giá và mô tả. Đây là ví dụ điển hình về phương thức HTTP PUT so với PATCH, trong đó PUT được sử dụng để thay thế toàn bộ tài nguyên sản phẩm.
Sản phẩm ban đầu:
| GET /products/1001{“id”: 1001,”name”: “Laptop”,”price”: 999.99,”description”: “Một chiếc laptop mạnh mẽ.”} |
Bạn muốn cập nhật giá và mô tả của sản phẩm. Bạn gửi yêu cầu PUT với toàn bộ tài nguyên:
Yêu cầu PUT:
| PUT /products/1001{“id”: 1001,”name”: “Laptop”,”price”: 899.99,”description”: “Laptop mạnh mẽ đang giảm giá.”} |
Nếu bạn thực hiện yêu cầu PUT này một hoặc nhiều lần, kết quả sẽ luôn giống nhau. Chi tiết sản phẩm sẽ được cập nhật để phản ánh giá và mô tả mới và kết quả sẽ giống nhau mỗi lần. Điều này đảm bảo tính chất bình thường của PUT.
Kết quả (Sau khi yêu cầu PUT):
| {“id”: 1001,”name”: “Laptop”,”price”: 899,99,”description”: “Một chiếc laptop mạnh mẽ đang được giảm giá.”} |
Kịch bản 2: Yêu cầu PATCH - Cập nhật một phần tài nguyên
Bây giờ, hãy xem xét yêu cầu PATCH để chỉ cập nhật một phần chi tiết của sản phẩm, chẳng hạn như mô tả. Ví dụ về API PATCH: Nếu bạn muốn thay đổi mô tả sản phẩm nhưng không muốn thay đổi giá của sản phẩm, PATCH là lựa chọn tốt hơn. Để triển khai điều này, bạn sẽ tạo các bản vá chỉ chứa các trường cần sửa đổi, chẳng hạn như mô tả trong ví dụ API REST PATCH này.
Sản phẩm ban đầu:
| GET /products/1001{“id”: 1001,”name”: “Laptop”,”price”: 999.99,”description”: “Một chiếc laptop mạnh mẽ.”} |
Yêu cầu VÁ:
| PATCH /products/1001{“description”: “Một chiếc máy tính xách tay nhẹ, mạnh mẽ.”} |
Khi bạn gửi yêu cầu PATCH này, chỉ trường mô tả mới được cập nhật. Nếu bạn gửi cùng một yêu cầu PATCH nhiều lần, mô tả sẽ không thay đổi sau lần cập nhật đầu tiên, khiến yêu cầu trở nên bình thường.
Kết quả (Sau khi yêu cầu PATCH):
| {“id”: 1001,”name”: “Laptop”,”price”: 999,99,”description”: “Một chiếc máy tính xách tay nhẹ, mạnh mẽ.”} |
Nếu bạn áp dụng lại PATCH tương tự, mô tả sản phẩm sẽ vẫn giống như sau PATCH đầu tiên. Kết quả là nhất quán, điều này làm cho PATCH trở nên bình thường trong trường hợp này.
Kịch bản 3: Yêu cầu PATCH - Hoạt động không bình thường
Chúng ta hãy xem xét một hoạt động PATCH không bình thường. Giả sử có một điểm cuối cho số dư ví của người dùng và bạn muốn tăng số dư. Một ví dụ khác biệt giữa PUT và PATCH có thể được minh họa ở đây: PATCH sẽ thêm một giá trị vào số dư mỗi lần
Ví ban đầu:
| NHẬN /users/1/wallet{“id”: 1,”balance”: 100,00} |
Yêu cầu VÁ:
| PATCH /users/1/wallet{“gia tăng”: 50,00} |
Yêu cầu PATCH này sẽ tăng số dư ví lên $50. Nếu bạn gửi yêu cầu PATCH này nhiều lần, số dư sẽ tiếp tục tăng theo mỗi PATCH, dẫn đến một kết quả khác nhau mỗi lần. Điều này không bình thường vì việc áp dụng cùng một PATCH nhiều lần sẽ gây ra một kết quả khác.
Kết quả (Sau yêu cầu PATCH đầu tiên):
| {“id”: 1,”cân bằng”: 150,00} |
Kết quả (Sau yêu cầu PATCH thứ hai):
| {“id”: 1,”số dư”: 200,00} |
Ở đây, PATCH không bình thường vì các yêu cầu lặp lại với cùng một dữ liệu sẽ tạo ra các kết quả khác nhau.
Tóm tắt: Sự khác biệt chính giữa PUT và PATCH trong API REST
Sự khác biệt chính giữa PUT và PATCH trong REST API là cách chúng xử lý các bản cập nhật. PUT thay thế toàn bộ tài nguyên nên mọi trường bị thiếu sẽ bị xóa, điều này có thể dẫn đến mất dữ liệu. Đây là lý do tại sao các nhà phát triển tạo bản vá để cập nhật một phần—để tránh ghi đè các trường không thay đổi và duy trì tính toàn vẹn của dữ liệu.
Điều này làm cho PATCH hiệu quả hơn khi cập nhật từng phần. Ví dụ về API PATCH là Nếu bạn chỉ muốn cập nhật email của người dùng, việc tạo bản vá sẽ chỉ gửi trường email, không giống như yêu cầu PUT yêu cầu toàn bộ dữ liệu người dùng.
Với PUT, cần có tải trọng dữ liệu đầy đủ. Điều này có nghĩa là mọi trường phải được gửi và mọi trường bị thiếu sẽ bị xóa. Tuy nhiên, PATCH chỉ gửi các trường cần cập nhật, giúp nó hiệu quả hơn, đặc biệt đối với các tài nguyên lớn với những thay đổi tối thiểu. Phương thức PATCH trong REST API cho phép các yêu cầu tập trung hơn và nhỏ hơn, giảm việc truyền dữ liệu.
Cả PUT và PATCH đều bình thường. Điều này có nghĩa là việc lặp lại cùng một yêu cầu sẽ dẫn đến kết quả tương tự. Tuy nhiên, PUT dễ dự đoán hơn vì nó thay thế toàn bộ tài nguyên. PATCH, khi chỉ được sử dụng để sửa đổi các trường được chỉ định, có thể dẫn đến các kết quả khác nhau tùy thuộc vào cách máy chủ xử lý các bản cập nhật.
Ví dụ: nếu PATCH tăng bộ đếm, các yêu cầu lặp lại có thể dẫn đến các kết quả khác nhau. Tuy nhiên, các hoạt động API PATCH cũng có thể được thiết kế bình thường.
Tóm lại, sự khác biệt giữa PUT và PATCH trong REST API tập trung vào bản chất của các bản cập nhật: PATCH dành cho những thay đổi một phần, trong khi PUT dành cho thay thế toàn bộ tài nguyên. Cả hai đều bình thường, nhưng PATCH có thể phức tạp hơn.
suy nghĩ cuối cùng
Cả PUT và PATCH đều là các phương thức HTTP cơ bản trong thiết kế API REST, nhưng chúng phục vụ các mục đích khác nhau, đó là bản chất của sự khác biệt giữa PUT và PATCH trong REST API. Bạn có thể cải thiện đáng kể hiệu quả, sự rõ ràng và chức năng của API bằng cách hiểu sự khác biệt giữa PUT và PATCH với các ví dụ chúng tôi đã đề cập trước đó trong bài viết này. Bằng cách chọn phương thức chính xác (PATCH so với cập nhật REST) dựa trên trường hợp sử dụng, bạn có thể làm cho API của mình hiệu quả hơn, dễ bảo trì hơn và thân thiện với người dùng hơn. Luôn xem xét bản chất của bản cập nhật—dù là toàn bộ hay một phần—cùng với tác động đến hiệu suất và tính toàn vẹn của dữ liệu, đồng thời chọn phương pháp phù hợp nhất với nhu cầu của bạn.
