Trong thiết kế RESTeful API, PUT và PATCH là hai phương pháp 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 vs PATCH trong REST APIs nằm ở cách thức thực hiện cập nhật và những tình huống mà mỗi phương pháp 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 rõ sự khác biệt giữa PUT và PATCH trong REST API có thể giúp lập trình viên đưa ra lựa chọn tốt nhất dựa trên bản chất của cập nhật họ cần thực hiện. Trong bài viết blog này, chúng tôi sẽ khám phá sự khác biệt giữa PUT và PATCH trong REST API, tập trung vào cuộc tranh luận PATCH vs cập nhật REST, khi nào sử dụng mỗi phương pháp, và cung cấp hướng dẫn chọn phương pháp phù hợp cho các trường hợp sử dụng khác nhau.
PUT trong REST APIs là gì?
Để hiểu rõ sự khác biệt giữa PUT và PATCH trong REST APIs, trước tiên chúng ta cần biết PUT là gì. Theo Phần 9.6 RFC 2616, phương thức PUT trong REST API yêu cầu thực thể được gửi kèm phải được lưu trữ tại Request-URI được cung cấp.
Nếu Request-URI chỉ đến một tài nguyên đã tồn tại, thực thể được gửi kèm NÊN được coi là phiên bản sửa đổi của tài nguyên trên máy chủ gốc. Nếu Request-URI không chỉ đến tài nguyên hiện có và URI đó có thể được định nghĩa thành tài nguyên mới bởi user agent yêu cầu, máy chủ gốc có thể tạo tài nguyên với URI đó.
Nói cách khác, phương thức PUT được 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.
Do đó, PUT phù hợp nhất cho các trường hợp sử dụng sau:
- Cập nhật toàn bộ tài nguyên (ví dụ: cập nhật hồ sơ người dùng với 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 nó cần được làm mới hoàn toàn.
Trong các hệ thống như Elasticsearch, các hoạt động idempotent 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 Elasticsearch sử dụ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 gây ra những hậu quả không mong muốn.
PATCH trong REST APIs là gì?
Giờ đây, sau khi đã tìm hiểu PUT trong REST APIs, hãy xem PATCH là gì trong REST APIs và cách hoạt động của nó trước khi so sánh PUT vs PATCH trong REST APIs. Theo định nghĩa trong RFC 5789, phương thức PATCH trong REST API 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 Request-URI.
Điều này phù hợp với sự phân biệt PUT vs PATCH REST API, nơi bạn chỉ gửi dữ liệu cần được sửa đổi, và máy chủ sẽ á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á để biểu thị những thay đổi tăng dần này, đảm bảo chuyể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 cho các trường hợp sử dụng sau:
- Cập nhật chỉ 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ụ PATCH API có thể liên quan đến việc gửi chỉ email mới, để các trường khác không bị ảnh hưởng.
- Cải thiện hiệu suất bằng cách giảm thiểu khối dữ liệu.
- Khi bạn muốn cập nhật tài nguyên từng bước thay vì thay thế nó hoàn toàn.
- Tạo các bản vá để đóng gói những thay đổi trường cụ thể, chẳng hạn 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, việc sử dụng PATCH cho các bản cập nhật nhỏ hơn như sửa đổi một trường duy nhất có thể giảm tải máy chủ và cải thiện hiệu suất.
Với hai phương thức này đã được trình bày, bạn đã có ý tưởng khá rõ về PUT và PATCH trong REST APIs. Tuy nhiên, trước khi đi vào sự khác biệt giữa PUT vs PATCH trong REST APIs, chúng ta cần nói về Idempotence trong hai phương thức này.
Tính Lũy Đẳng Trong PUT Vs PATCH trong REST APIs
Trong REST APIs, tính lũy đẳng (idempotence) là tính chất của một phép toán mà khi thực hiện lặp lại nhiều lần với cùng các đầu vào, sẽ cho ra kết quả giống nhau. Điều này có nghĩa là thực hiện cùng một yêu cầu nhiều lần sẽ có tác động giống nhau trên máy chủ, bất kể thực hiện bao nhiêu lần. Điều này rất quan trọng để đảm bảo tính ổn định và dự đoán được trong một API. Nhưng làm sao nó liên quan đến sự khác nhau giữa PUT và PATCH trong REST API?
Phương Pháp PUT và Tính Lũy Đẳng
Phương thức PUT trong REST API luôn lũy đẳng vì nó được thiết kế để thay thế toàn bộ tài nguyên tại một URI cụ thể 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 dữ liệu tài nguyên, kết quả sẽ luôn giống nhau.
Tại sao PUT lũy đẳng? Khi bạn thực hiện yêu cầu PUT, bạn về cơ bản đang nói với máy chủ: "Đây là trạng thái hoàn chỉnh và chính xác mà tôi muốn cho tài nguyên này." Dù bạn gửi 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 tình huống bạn cập nhật địa chỉ email của một người dùng. Nếu bạn thực hiện cùng yêu cầu PUT nhiều lần, kết quả sẽ không thay đổi vì tài nguyên được thay thế bằng cùng dữ liệu mỗi lần.
Ví dụ:
| PUT /users/1{"username": "john_doe","email": "[email protected]"} |
Nếu bạn gửi yêu cầu này nhiều lần, kết quả sẽ luôn giống nhau:
| {"username": "john_doe","email": "[email protected]"} |
Ngay cả khi dữ liệu người dùng đã là như vậy, gửi yêu cầu lại không thay đổi gì cả. Nó thay thế dữ liệu bằng chính dữ liệu đó, vì vậy tác động của yêu cầu vẫn giống nhau bất kể lặp lại bao nhiêu lần. Đó là lý do tại sao PUT lũy đẳng.
Phương Pháp PATCH và Tính Lũy Đẳng
Phương thức PATCH trong REST API, mặt khác, nói chung cũng lũy đẳ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 phép toán là lũy đẳng (ví dụ: đặt một giá trị) để tránh các tác động không mong muốn từ các yêu cầu lặp lại. Việc PATCH lũy đẳng hay không phụ thuộc vào phép toán và dữ liệu được sửa đổi.
Tại sao PATCH lũy đẳng? Đối với các yêu cầu PATCH, tính lũy đẳng có nghĩa là áp dụng cùng một bản vá nhiều lần sẽ có cùng kết quả. Điều này đúng miễn là bản vá đó không gây ra các tác động phụ hoặc thay đổi bổ sung khi được áp dụng lặp lại. Nếu bạn tiếp tục áp dụng cùng một bản vá với cùng 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 lặp lại cùng 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ẽ vẫn giữ nguyên và trạng thái của tài nguyên sẽ không thay đổi.
Ví dụ PATCH API:
| PATCH /users/1{"email": "[email protected]"} |
Nếu email đã là [email protected], thì áp dụng PATCH này lại sẽ không có thay đổi gì, làm cho nó lũy đẳng.
Tuy nhiên, PATCH cũng có thể không lũy đẳng trong một số trường hợp. Ví dụ, nếu một phép toán PATCH sửa đổi một bộ đếm hoặc thêm mục vào danh sách (chẳng hạn như tăng một số hoặc nối thêm vào một mảng), việc áp dụng lặp lại 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 lũy đẳng.
Ví dụ PATCH không lũy đẳng API REST:
| PATCH /counter/1{"increment": 1} |
Nếu bạn áp dụng PATCH này lặp lại, 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 lũy đẳng vì kết quả thay đổi với mỗi lần áp dụng.
Bây giờ bạn đã biết những điều cơ bản, chúng ta có thể xem một số tình huống ví dụ để hiểu rõ hơn sự khác nhau giữa PUT và PATCH trong REST APIs.
Ví dụ: PUT vs PATCH trong REST APIs
Bỏ qua lý thuyết, hãy xem xét sự khác nhau giữa PUT và PATCH với các ví dụ, bao gồm cả các phép toán lũy đẳng và không lũy đẳng.
Tình huống 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 một hệ thống thương mại điện tử. Bạn cần cập nhật tất cả chi tiết của một sản phẩm, bao gồm tên, giá và mô tả của nó. Đây là một ví dụ điển hình về HTTP phương thức PUT so với PATCH, nơi 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": "A powerful laptop."} |
Bạn muốn cập nhật giá và mô tả của sản phẩm. Bạn gửi một 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": "A discounted powerful laptop."} |
Nếu bạn thực hiện yêu cầu PUT này một lần hoặc nhiều lần, kết quả sẽ luôn như nhau. Chi tiết sản phẩm sẽ được cập nhật để phản ánh giá và mô tả mới, và cùng một kết quả sẽ xảy ra mỗi lần. Điều này đảm bảo tính chất idempotent của PUT.
Kết quả (Sau yêu cầu PUT):
| {"id": 1001,"name": "Laptop","price": 899.99,"description": "A discounted powerful laptop."} |
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 một yêu cầu PATCH để cập nhật chỉ một phần chi tiết sản phẩm, chẳng hạn như mô tả. Ví dụ PATCH API: Nếu bạn muốn thay đổi mô tả sản phẩm nhưng không thay đổi giá của nó, 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ứa chỉ các trường cần sửa đổi, chẳng hạn như mô tả trong ví dụ PATCH API REST này.
Sản phẩm Ban đầu
| GET /products/1001{"id": 1001,"name": "Laptop","price": 999.99,"description": "A powerful laptop."} |
Yêu cầu PATCH:
| PATCH /products/1001{"description": "A lightweight, powerful laptop."} |
Khi bạn gửi yêu cầu PATCH này, chỉ trường mô tả sẽ đượ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ẽ vẫn không thay đổi sau lần cập nhật đầu tiên, làm cho yêu cầu trở nên idempotent.
Kết quả (Sau yêu cầu PATCH):
| {"id": 1001,"name": "Laptop","price": 999.99,"description": "A lightweight, powerful laptop."} |
Nếu bạn áp dụng cùng một PATCH lần nữa, mô tả sản phẩm vẫn sẽ giống như sau lần PATCH đầu tiên. Kết quả là nhất quán, điều này làm cho PATCH trở nên idempotent trong kịch bản này.
Kịch bản 3: Yêu cầu PATCH - Hoạt động không idempotent
Hãy xem xét một hoạt động PATCH không idempotent. 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ư. Sự khác biệt ví dụ 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:
| GET /users/1/wallet{"id": 1,"balance": 100.00} |
Yêu cầu PATCH:
| PATCH /users/1/wallet{"increment": 50.00} |
Yêu cầu PATCH này sẽ tăng số dư ví lên 50 đô la. 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 với mỗi PATCH, dẫn đến một kết quả khác nhau mỗi lần. Đây là non-idempotent vì áp dụng cùng một PATCH nhiều lần sẽ gây ra một kết quả khác nhau.
Kết quả (Sau yêu cầu PATCH đầu tiên):
| {"id": 1,"balance": 150.00} |
Kết quả (Sau yêu cầu PATCH thứ hai):
| {"id": 1,"balance": 200.00} |
Ở đây, PATCH không phải idempotent 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 REST APIs
Sự khác biệt chính giữa PUT vs PATCH trong REST API là cách chúng xử lý các cập nhật. PUT thay thế toàn bộ tài nguyên, vì vậy bất kỳ trường nào 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 các bản vá cho các cập nhật từng 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 cho các cập nhật từng phần. Ví dụ về PATCH API là nếu bạn muốn cập nhật chỉ email của người dùng, việc tạo các bản vá sẽ chỉ gửi trường email, không giống như yêu cầu PUT sẽ yêu cầu toàn bộ dữ liệu người dùng.
Với PUT, toàn bộ tải dữ liệu được yêu cầu. Điều này có nghĩa là mọi trường phải được gửi, và bất kỳ trường nào bị thiếu sẽ bị xóa. PATCH, tuy nhiên, chỉ gửi các trường cần được cập nhật, làm cho nó hiệu quả hơn, đặc biệt là đối với các tài nguyên lớn với các 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 truyền dữ liệu.
Cả PUT và PATCH đều là idempotent. Điều này có nghĩa là lặp lại cùng một yêu cầu sẽ dẫn đến cùng một kết quả. Tuy nhiên, PUT có thể dự đoán được hơn vì nó thay thế toàn bộ tài nguyên. PATCH, khi được sử dụng để sửa đổi chỉ 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 cập nhật.
Ví dụ, nếu một 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 PATCH API cũng có thể được thiết kế để trở nên idempotent.
Tóm lại, sự khác biệt giữa PUT và PATCH trong REST API là dựa trên bản chất của các cập nhật: PATCH là cho các thay đổi từng phần, trong khi PUT là để thay thế toàn bộ tài nguyên. Cả hai đều là idempotent, nhưng PATCH có thể phức tạp hơn.
Suy nghĩ cuối cùng
Cả PUT và PATCH đều là những phương thức cơ bản HTTP trong thiết kế REST API, 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ả, độ 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ụ mà chúng tôi đã trình bày trước đó trong bài viết này. Bằng cách chọn phương thức chính xác (PATCH vs cập nhật REST) dựa trên trường hợp sử dụng của bạn, bạn có thể làm cho API của mình hiệu quả hơn, dễ bảo trì và thân thiện hơn với người dùng. Luôn cân nhắc bản chất của cập nhật - cho dù đó là toàn bộ hay từng 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, và lựa chọn phương thức phù hợp nhất với nhu cầu của bạn.
