Mã trạng thái 204 No Content là gì: Âm thanh của thành công

Bạn đang sử dụng một ứng dụng web được thiết kế tốt. Bạn xóa một mục khỏi danh sách, cập nhật cài đặt hoặc đánh dấu một nhiệm vụ là hoàn thành. Hành động diễn ra ngay lập tức và liền mạch. Không có thông báo "Thành công!" rực rỡ, không có dữ liệu mới nào tải trên màn hình, chỉ có sự xác nhận thầm lặng, tự tin rằng những gì bạn định làm đã được thực hiện. Trải nghiệm người dùng tối giản, tinh tế này thường được cung cấp bởi một trong những mã trạng thái HTTP bị hiểu lầm và đánh giá thấp nhất: **`204 No Content`**. Không giống như người anh em lắm lời `200 OK`, luôn có điều gì đó để nói, mã trạng thái `204` là kiểu người mạnh mẽ, trầm lặng của thế giới HTTP. Đó là cách máy chủ đưa ra một cái "OK" đơn giản, một cái gật đầu xác nhận. Nó nói, "Tôi đã xử lý yêu cầu của bạn thành công. Không có gì để tôi gửi lại cho bạn, và đó chính xác là những gì nên diễn ra." Vậy, nó có nghĩa là gì? Tại sao nó tồn tại? Và quan trọng hơn, bạn nên sử dụng nó như thế nào trong các API của mình? Nếu bạn là nhà phát triển xây dựng API hoặc ứng dụng web, việc hiểu và triển khai đúng cách `204 No Content` là một dấu hiệu của sự chuyên nghiệp và là chìa khóa để tạo ra các hệ thống hiệu quả, gọn gàng và dễ đoán. Nếu bạn muốn thử nghiệm cách `204 No Content` hoạt động trong các API thực tế, bạn không cần phải tạo một máy chủ tùy chỉnh. Thay vào đó, bạn chắc chắn nên dùng thử Apidog, một công cụ kiểm thử và tài liệu API miễn phí. Apidog giúp bạn dễ dàng kiểm thử API của mình và xem chính xác cách các mã trạng thái khác nhau, như 204, hoạt động trong các tình huống thực tế. Hơn nữa, nó giúp bạn tạo tài liệu và cộng tác với nhóm của mình một cách liền mạch. Tải Apidog miễn phí và có được sự hiểu biết rõ ràng, thực tế hơn về phản hồi API của bạn khi chúng ta khám phá mã trạng thái 204! Tải ứng dụng Bây giờ, hãy cùng phân tích HTTP 204 No Content bằng ngôn ngữ đơn giản và đi sâu vào lý do tại sao nó quan trọng.

HTTP 204 No Content thực sự có nghĩa là gì?

Mã trạng thái 204 No Content cho máy khách biết rằng yêu cầu đã thành công, nhưng máy chủ không gửi bất kỳ nội dung nào trong phần thân phản hồi. Điều này thoạt nghe có vẻ lạ – làm thế nào một yêu cầu có thể thành công mà không gửi dữ liệu? Nhưng thực ra, đây là một tín hiệu rất hữu ích và có chủ ý trong phát triển web. Định nghĩa chính thức (từ RFC 7231) rất ngắn gọn: Hãy phân tích các phần chính:

• "Máy chủ đã thực hiện yêu cầu thành công...": Điều này rất quan trọng. Đó là một mã thành công hoàn toàn. Hoạt động, dù là xóa, cập nhật hay chuyển đổi, đã hoàn thành mà không gặp trở ngại nào.
• "...không có nội dung bổ sung để gửi...": Máy chủ không có gì để nói. Không cần chuyển dữ liệu trở lại máy khách để thông báo thành công này.
• "...trong phần thân phản hồi.": Phản hồi sẽ có các tiêu đề và dòng trạng thái, nhưng phần thân sẽ trống rỗng một cách có chủ ý. Điều này giúp tiết kiệm băng thông và thời gian xử lý.

Trong thực tế, một phản hồi 204 trông như thế này:

HTTP/1.1 204 No ContentX-RateLimit-Limit: 1000X-RateLimit-Remaining: 999

Chỉ vậy thôi. Không có phần thân. Không có tiêu đề Content-Length. Chỉ là một xác nhận sạch sẽ, hiệu quả. Bất cứ khi nào máy khách gửi một yêu cầu không cần phần thân phản hồi đầy đủ, ví dụ, sau khi gửi dữ liệu biểu mẫu, xóa tài nguyên hoặc thực hiện một hành động mà không cần nội dung bổ sung, máy chủ có thể phản hồi bằng 204. Điều này cho máy khách biết, "Yêu cầu của bạn đã được xử lý chính xác, nhưng không có gì mới để hiển thị cho bạn." Một ví dụ kinh điển: Hãy tưởng tượng bạn yêu cầu bạn mình đổ rác. Họ làm xong, quay lại và không nói gì vì công việc đã hoàn thành, và không có gì khác để báo cáo. Đó chính là 204 trong hành động.

Các đặc điểm chính của 204

Đây là điều làm cho 204 trở nên độc đáo:

• Đó là một mã thành công: Yêu cầu đã hoàn thành thành công.
• Không cho phép phần thân: Phản hồi không được bao gồm phần thân thông báo.
• Vẫn có thể có tiêu đề: Bạn vẫn có thể gửi các tiêu đề như Content-Type hoặc ETag.
• Hiệu quả: Tiết kiệm băng thông vì không có tải trọng.

Tại sao mã trạng thái 204 tồn tại?

Bạn có thể tự hỏi, chẳng lẽ máy chủ không thể chỉ phản hồi bằng 200 OK và một phần thân thông báo trống nếu không có nội dung? Đây là lý do tại sao mã trạng thái 204 quan trọng:

• Hiệu quả: Nó giảm truyền dữ liệu không cần thiết, đặc biệt hữu ích cho mạng di động hoặc băng thông hạn chế.
• Hành vi của máy khách: Một số máy khách diễn giải phản hồi 204 khác với phản hồi 200 trống. Ví dụ, trình duyệt sẽ không cố gắng làm mới hoặc tải lại trang dựa trên phản hồi 204.
• Rõ ràng về ngữ nghĩa: 204 truyền đạt rõ ràng ý định—nó nói rằng yêu cầu đã thành công, nhưng đơn giản là không có nội dung để gửi.
• Tránh các thay đổi giao diện người dùng không mong muốn: Trong một số ứng dụng web, việc gửi 204 ngăn chặn việc tải lại trang hoặc nhấp nháy giao diện không mong muốn.

Về cơ bản, 204 hợp lý hóa giao tiếp giữa máy chủ và máy khách bằng cách cho cả hai bên biết rằng không cần thay đổi nội dung.

Tại sao chúng ta cần 204 No Content?

Bạn có thể tự hỏi: Tại sao không chỉ sử dụng 200 OK và trả về một phần thân trống? Câu hỏi hay. Câu trả lời nằm ở giao tiếp rõ ràng giữa máy chủ và máy khách.

• 200 OK ngụ ý rằng có thể có một phần thân phản hồi.
• 204 No Content làm rõ ràng: "Không có nội dung ở đây, và đó là có chủ ý."

Sự khác biệt này giúp các máy khách như trình duyệt, ứng dụng di động hoặc người tiêu dùng API biết rằng họ không cần xử lý hoặc phân tích một phần thân.

Khi nào nên sử dụng 204 No Content: Sự phù hợp hoàn hảo

Bạn nên sử dụng mã trạng thái 204 trong một tình huống chính: Khi yêu cầu của máy khách đã thành công và máy khách không cần thay đổi trạng thái hoặc giao diện của nó theo bất kỳ cách nào ngoài những gì đã được ngụ ý bởi chính yêu cầu đó. Hãy xem xét một số ví dụ kinh điển:

1. Trường hợp sử dụng tiêu biểu: Các hoạt động DELETE

Đây là trường hợp sử dụng phổ biến và phù hợp nhất cho 204. Khi máy khách xóa một tài nguyên, máy chủ nên gửi lại gì? Tài nguyên đã xóa? Điều đó không có ý nghĩa. Một thông báo nói "Nó đã bị xóa"? Mã trạng thái 204chính là thông báo đó.

• Yêu cầu: DELETE /api/articles/123
• Phản hồi: 204 No Content
• Hành vi của máy khách: Máy khách biết bài viết đã biến mất. Nó có thể xóa bài viết đó khỏi trạng thái giao diện người dùng cục bộ của mình. Không cần thêm thông tin nào nữa.

2. Cập nhật tài nguyên bằng PUT/PATCH

Khi máy khách cập nhật một tài nguyên bằng PUT hoặc PATCH, nó đã có bản biểu diễn hoàn chỉnh của tài nguyên mà nó muốn. Nếu việc cập nhật thành công, máy chủ thường không cần gửi lại toàn bộ tài nguyên.

• Yêu cầu: PATCH /api/users/me { "theme": "dark" }
• Phản hồi: 204 No Content
• Hành vi của máy khách: Máy khách đã biết trạng thái mới mong muốn ("theme": "dark"). Nó có thể giả định rằng việc cập nhật đã thành công và áp dụng thay đổi vào trạng thái cục bộ của nó ngay lập tức. Một 204 hiệu quả hơn việc máy chủ lặp lại toàn bộ đối tượng người dùng.

3. Các hành động chuyển đổi

Các hành động chỉ đơn giản là chuyển đổi trạng thái rất phù hợp với 204.

• Yêu cầu: POST /api/notifications/456/mark-as-read
• Phản hồi: 204 No Content
• Hành vi của máy khách: Máy khách có thể thay đổi trạng thái hiển thị của thông báo từ "chưa đọc" sang "đã đọc" trong giao diện người dùng. Không cần thêm dữ liệu nào.

204 so với 200 OK: Một sự khác biệt quan trọng

Đây là nơi nhiều nhà phát triển mắc lỗi. Liệu có ổn không khi chỉ sử dụng 200 OK với một phần thân trống? Về mặt kỹ thuật, có. Nhưng về mặt ngữ nghĩa, 204 là lựa chọn tốt hơn, chính xác hơn.

• Một 200 OK với phần thân trống gửi một thông điệp lẫn lộn. Nó nói, "Đây là một phản hồi thành công! (Nhưng tôi không có gì để cho bạn xem)." Nó giống như một người phục vụ nói, "Đây là bữa ăn của bạn!" và đưa ra một đĩa trống.
• Một 204 No Content rõ ràng và không mơ hồ. Nó nói, "Thành công. Và tôi không có gì để cho bạn xem vì bạn đã có mọi thứ bạn cần." Nó giống như người phục vụ giơ ngón tay cái từ phía bên kia căn phòng sau khi bạn đã ăn xong bữa, xác nhận rằng họ đã thấy bạn và không cần hành động gì thêm.

Sử dụng 204 đúng cách là dấu hiệu của một API được thiết kế tốt, chu đáo.

Các trường hợp sử dụng phổ biến cho 204 No Content

Hãy xem xét một số kịch bản thực tế mà bạn có thể thấy hoặc muốn sử dụng 204 No Content:

• Xóa tài nguyên: Khi máy khách xóa một mục thông qua API (ví dụ: DELETE /users/123), máy chủ có thể phản hồi bằng 204 để báo hiệu rằng tài nguyên đã được xóa thành công và không có gì để trả về.
• Cập nhật tài nguyên mà không trả về nó: Đôi khi các yêu cầu PUT hoặc PATCH cập nhật một tài nguyên nhưng không cần gửi lại dữ liệu đã cập nhật ngay lập tức, vì vậy 204 là phù hợp.
• Gửi biểu mẫu: Khi gửi biểu mẫu qua AJAX, một 204 cho máy khách biết rằng việc gửi đã thành công nhưng không có nội dung mới nào để tải hoặc hiển thị.
• Điểm cuối ping hoặc heartbeat: Đối với kiểm tra sức khỏe hoặc giữ kết nối, phản hồi 204 cho biết thành công mà không cần gửi dữ liệu không cần thiết.
• Không cần thay đổi giao diện người dùng: Trong các ứng dụng trang đơn (SPA), các cuộc gọi backend không cần cập nhật giao diện người dùng có thể hưởng lợi từ 204.

204 so với 200: Sự khác biệt là gì?

Đây là một trong những sự nhầm lẫn lớn nhất của các nhà phát triển.

• 200 OK: Yêu cầu thành công và phản hồi có thể chứa nội dung.
• 204 No Content: Yêu cầu thành công và phản hồi không được chứa nội dung.

Vì vậy, nếu bạn muốn trả về JSON, XML hoặc HTML, hãy sử dụng 200. Nếu không, hãy sử dụng 204.

204 so với 202: Một sự nhầm lẫn phổ biến khác

Một người anh em họ gần gũi khác là 202 Accepted.

• 202 Accepted: Yêu cầu đã được nhận nhưng chưa được xử lý. Việc xử lý có thể xảy ra sau.
• 204 No Content: Yêu cầu đã được nhận và xử lý ngay lập tức, và không có gì để nói thêm.

Nói cách khác, 202 là "Tôi sẽ làm nó", trong khi 204 là "Tôi đã làm nó rồi".

204 so với 404 Not Found cho DELETE

Một điểm nhầm lẫn phổ biến khác: Yêu cầu DELETE nên trả về gì nếu tài nguyên không tồn tại?

• Trả về 204 No Content nếu trạng thái cuối cùng mong muốn đã đạt được. Nếu mục tiêu là tài nguyên không còn nữa, và nó đã không còn, thì hoạt động đó đã thành công. Điều này là tính bất biến—thực hiện cùng một yêu cầu nhiều lần có cùng một hiệu ứng.
• Trả về 404 Not Found chỉ khi định dạng ID sai hoặc tài nguyên chưa bao giờ tồn tại theo cách mà máy khách có thể mong đợi một cách hợp lý. Ví dụ, xóa /api/articles/not-a-real-id có thể trả về 404.

Quy tắc chung: Nếu yêu cầu DELETE thành công trong việc đạt được mục tiêu của nó (tài nguyên không còn ở đó), hãy trả về 204.

Công việc của máy khách: Xử lý phản hồi 204

Một máy khách hoạt động tốt phải biết cách xử lý phản hồi 204 một cách chính xác.

1. Không cố gắng phân tích phần thân: Phản hồi không có phần thân. Bất kỳ nỗ lực nào để phân tích JSON, XML hoặc văn bản từ phản hồi sẽ dẫn đến lỗi. Mã của bạn nên kiểm tra mã trạng thái trước và chỉ cố gắng phân tích phần thân cho các mã như 200.
2. Coi đó là thành công: Máy khách nên diễn giải 204 là một thành công hoàn toàn và cập nhật trạng thái nội bộ của nó cho phù hợp (ví dụ: xóa một mục khỏi danh sách, cập nhật một nút chuyển đổi giao diện người dùng).
3. Tôn trọng các tiêu đề: Mặc dù không có phần thân, có thể có siêu dữ liệu quan trọng trong các tiêu đề (như thông tin giới hạn tốc độ). Luôn đọc các tiêu đề.

Trong các trình duyệt web, phản hồi 204 không kích hoạt tải lại trang hoặc thay đổi điều hướng, làm cho nó hữu ích cho các cuộc gọi AJAX sửa đổi dữ liệu ở chế độ nền.

Cách các nhà phát triển có thể triển khai mã trạng thái 204 một cách chính xác

Để đảm bảo bạn tận dụng tối đa mã trạng thái 204:

• Xác nhận rằng máy khách không mong đợi phần thân phản hồi.
• Gửi các tiêu đề phù hợp nếu cần (ví dụ: Content-Type thường bị bỏ qua vì không có phần thân).
• Tránh bao gồm phần thân phản hồi; làm như vậy có thể gây ra hành vi không xác định ở một số máy khách.
• Tài liệu hóa việc sử dụng rõ ràng trong tài liệu API của bạn.

Lợi ích của việc sử dụng 204 đúng cách

• Tiết kiệm băng thông: Không có phần thân phản hồi không cần thiết.
• Ý định rõ ràng: Truyền đạt rằng sự im lặng là có chủ ý, không phải ngẫu nhiên.
• Hiệu quả của máy khách: Ngăn máy khách lãng phí chu kỳ phân tích các phần thân trống.
• Tuân thủ tiêu chuẩn: Giúp đảm bảo API của bạn tuân thủ các thực tiễn tốt nhất của HTTP.

Kiểm thử phản hồi 204 với Apidog

Kiểm thử các điểm cuối trả về 204 là rất quan trọng. Bạn cần đảm bảo chúng trả về mã trạng thái chính xác và không vô tình làm rò rỉ dữ liệu vào phần thân phản hồi. Apidog là công cụ hoàn hảo cho việc này. Với Apidog, bạn có thể:

1. Tạo yêu cầu: Dễ dàng thiết lập yêu cầu DELETE hoặc PUT đến điểm cuối của bạn.
2. Gửi và xác thực: Với một cú nhấp chuột, gửi yêu cầu và ngay lập tức xem phản hồi đầy đủ.
3. Kiểm tra chi tiết: Apidog sẽ hiển thị rõ ràng mã trạng thái (204) và tất cả các tiêu đề. Quan trọng là, nó sẽ hiển thị ngăn phần thân phản hồi trống, xác nhận API của bạn đang hoạt động chính xác.
4. Viết xác nhận: Bạn có thể viết các tập lệnh kiểm thử tự động trong Apidog để xác nhận trạng thái phản hồi là 204 và phần thân phản hồi thực sự trống. Điều này ngăn chặn các lỗi hồi quy.
5. Gỡ lỗi: Nếu điểm cuối của bạn vô tình trả về một phần thân với 204, hoặc trả về 200 khi nó nên trả về 204, Apidog sẽ làm cho lỗi này hiển thị ngay lập tức.
6. Tài liệu rõ ràng: Apidog cho phép bạn tài liệu hóa các điểm cuối nào trả về 204 và trong điều kiện nào, giúp nhóm của bạn và người tiêu dùng API.
7. Cộng tác: Chia sẻ thông số kỹ thuật API với nhóm của bạn để có quy trình phát triển và gỡ lỗi tốt hơn.

Tải ứng dụngMức độ kiểm thử này rất cần thiết để xây dựng các API chuyên nghiệp, đáng tin cậy. Bằng cách tích hợp Apidog vào quy trình phát triển của bạn, việc xử lý các mã trạng thái như 204 trở nên minh bạch và dễ quản lý.

Apidog so với các công cụ API khác để mô phỏng 204

Hãy so sánh:

• Postman: Tuyệt vời để kiểm thử thủ công, nhưng việc mô phỏng hành vi 204 có thể cảm thấy cồng kềnh.
• Swagger UI: Hữu ích cho tài liệu nhưng không mô phỏng phản hồi tốt.
• Apidog: Kết hợp kiểm thử, mô phỏng và tài liệu trong một nền tảng. Hoàn hảo để thử nghiệm các trường hợp đặc biệt như 204.

Những hiểu lầm phổ biến về 204 No Content

Dễ dàng nhầm lẫn 204 với các mã trạng thái khác hoặc hiểu sai mục đích sử dụng của nó:

• 204 có nghĩa là lỗi hoặc thất bại: Không đúng! Đó là một trạng thái thành công mà không có nội dung.
• 204 chỉ dành cho các phản hồi trống: Nó dành cho việc xử lý thành công với các phản hồi trống có chủ ý, không phải lỗi.
• 204 cho phép phần thân thông báo: Theo thông số kỹ thuật HTTP, 204 không được bao gồm phần thân thông báo.
• 204 có nghĩa là hoàn toàn không có phản hồi: Máy chủ vẫn gửi các tiêu đề và dòng trạng thái, chỉ là không có phần thân thông báo.

Những lỗi phổ biến và các mẫu chống

• Trả về 200 OK với { "success": true }: Điều này lãng phí và ít ngữ nghĩa hơn một 204 đơn giản. Mã trạng thái chính là chỉ báo thành công.
• Trả về một phần thân với 204: Điều này vi phạm đặc tả HTTP. Phản hồi 204 KHÔNG ĐƯỢC bao gồm phần thân thông báo.
• Sử dụng 204 cho yêu cầu GET: Yêu cầu GET luôn phải trả về một biểu diễn của tài nguyên. Nếu không có gì để trả về, có thể phù hợp hơn khi trả về 200 OK với một mảng trống [] hoặc một đối tượng trống {}, hoặc có thể là 404 nếu không tìm thấy tài nguyên cụ thể.

Những cách lạm dụng phổ biến của 204 No Content

Thật không may, các nhà phát triển thường lạm dụng 204. Dưới đây là một vài cạm bẫy:

• Trả về 204 với phần thân → Điều này vi phạm đặc tả HTTP.
• Sử dụng 204 thay vì 200 khi phần thân phản hồi được mong đợi.
• Trả về 204 cho các yêu cầu GET → Các yêu cầu GET hầu như luôn phải trả về nội dung.

Điều gì xảy ra nếu 204 bị lạm dụng?

Lạm dụng 204 có thể dẫn đến hành vi máy khách lạ:

• Bao gồm phần thân với 204 có thể khiến máy khách bị treo hoặc gặp lỗi.
• Tránh gửi 204 khi tài nguyên thực sự bị thiếu; 404 tốt hơn.
• Giao tiếp sai có thể dẫn đến trạng thái giao diện người dùng khó hiểu hoặc bộ nhớ đệm không phù hợp.

Do đó, việc hiểu và tuân thủ mục đích sử dụng của 204 là rất cần thiết.

Các thực tiễn tốt nhất để triển khai 204 trong REST API

• Sử dụng 204 chủ yếu cho các hoạt động DELETE và cập nhật.
• Không bao gồm phần thân phản hồi.
• Thêm các tiêu đề có ý nghĩa nếu cần (như Location hoặc ETag).
• Tài liệu hóa hành vi để người tiêu dùng API biết điều gì sẽ xảy ra.

204 trong GraphQL, gRPC và các giao thức khác

• GraphQL: Hiếm khi sử dụng 204, vì mỗi truy vấn đều mong đợi một tải trọng phản hồi.
• gRPC: Thay vì mã trạng thái HTTP, gRPC có các mã lỗi riêng, nhưng khái niệm "không có nội dung" đôi khi được phản ánh bằng OK cộng với không có tải trọng.
• SOAP API: Trong lịch sử, 204 không phổ biến, vì các thông báo SOAP thường luôn bao gồm một phong bì.

Tìm hiểu sâu: Cách 204 hoạt động với RESTful API

Trong thiết kế RESTful, các phản hồi rất quan trọng để hướng dẫn hành vi của máy khách. Vì nhiều hành động có thể không yêu cầu trả về toàn bộ tài nguyên đã cập nhật hoặc bất kỳ nội dung nào, 204 là một cách thanh lịch để tiết kiệm băng thông và cải thiện khả năng phản hồi. Ví dụ, trong các hoạt động CRUD của RESTful:

• GET: Trả về 200 và dữ liệu tài nguyên.
• POST: Trả về 201 Created với dữ liệu tài nguyên mới.
• PUT: Có thể trả về 204 nếu không có dữ liệu cập nhật nào được gửi lại.
• DELETE: Thường trả về 204 để xác nhận xóa mà không có nội dung.

Triết lý thiết kế này phù hợp với các API web hiện đại, hiệu quả.

Kết luận: Nắm bắt sức mạnh của 204 No Content

Mã trạng thái 204 No Content có vẻ đơn giản, nhưng nó giữ một vị trí quan trọng trong giao tiếp HTTP bằng cách báo hiệu thành công mà không cần truyền dữ liệu không cần thiết. Nó tiết kiệm băng thông, cải thiện trải nghiệm người dùng và làm rõ giao tiếp giữa máy chủ và máy khách. Mã trạng thái HTTP 204 No Content là một kiệt tác của thiết kế tối giản. Nó thể hiện nguyên tắc rằng giao tiếp hiệu quả nhất thường chỉ nói đủ và không hơn. Trong một thế giới của các phản hồi JSON cồng kềnh và các API được thiết kế quá mức, việc sử dụng đúng 204 là dấu hiệu của một nhà phát triển hiểu rõ các sắc thái của giao thức HTTP và tôn trọng cả tài nguyên của máy khách và máy chủ. Đó không phải là một mã của sự vắng mặt; đó là một mã của sự hoàn thành. Đó là tiếng "click" thỏa mãn của một cánh cửa được đóng kín, mảnh ghép cuối cùng của một câu đố khớp vào vị trí. Đó là âm thanh của thành công, và âm thanh đó là sự im lặng. Nếu bạn đang xây dựng API, hãy sử dụng 204 cẩn thận:

• Tuyệt vời cho các hành động DELETE và cập nhật.
• Tránh dùng cho GET.
• Tài liệu hóa nó thật tốt.

Nếu bạn phát triển hoặc sử dụng API, việc nắm vững cách sử dụng và phản hồi 204 sẽ làm cho các ứng dụng của bạn hiệu quả hơn và thân thiện với người dùng hơn. Vì vậy, lần tới khi bạn xây dựng một điểm cuối cho hành động DELETE, PUT hoặc chuyển đổi, đừng chỉ mặc định dùng 200 OK. Hãy đón nhận sự tinh tế của 204 No Content. Và hãy nhớ, cách tốt nhất để học là thực hành. Đừng quên tải Apidog miễn phí. Sử dụng một công cụ như Apidog để đảm bảo việc triển khai của bạn chính xác, hiệu quả và hoàn toàn tuân thủ, làm cho các API của bạn trở nên dễ sử dụng và là một tiêu chuẩn chất lượng. Apidog giúp việc kiểm thử, tài liệu hóa và làm việc với các mã trạng thái HTTP khác nhau như 204 trở nên dễ dàng và hiệu quả, đảm bảo hành vi API của bạn rõ ràng và nhất quán. Tải ứng dụng