Bất ngờ chưa? API của bạn chẳng cần PUT, PATCH, DELETE đâu!

Lê Lân

20/06/2025

Hot Take: API Của Bạn Không Cần PUT, PATCH, DELETE Hay Những Thứ “Học Thuật” Khác

Mở Đầu

REST - một kiến trúc API phổ biến - đang trở nên ngày càng khó áp dụng trong phát triển web hiện đại. Nhiều nhà phát triển từng chán nản với sự phức tạp của PUT, PATCH, DELETE và hàng loạt luân lý HTTP khác.

Trong bối cảnh năm 2025, cách xây dựng API của bạn có thể cần được thay đổi để phù hợp hơn với thực tế phát triển ứng dụng hiện đại. Bài viết này sẽ chỉ ra lý do tại sao những HTTP phương thức như PUT, PATCH, DELETE có thể trở nên dư thừa, đồng thời giới thiệu một giải pháp đơn giản hơn dựa trên POST và định dạng dữ liệu TOML, giúp API vừa dễ hiểu vừa hiệu quả hơn trong thực tế.

Chúng ta sẽ đi qua: cái gọi là “rạp xiếc REST” trong thực tiễn; cách mà frontend hiện đại xử lý việc định tuyến; backend thực sự cần gì; lý do PUT/PATCH/DELETE chỉ là “đoản kịch” của REST; lý do TOML là “kẻ hủy diệt JSON”; và cuối cùng là ví dụ thực tế so sánh với các API truyền thống.

Thực Trạng REST Trong Năm 2025

Các Kiểu API Thường Gặp

Bạn có thể đã quen với các loại API sau:

API REST "thuần túy":

GET /users/123      // Lấy thông tin người dùng
POST /users         // Tạo người dùng mới
PUT /users/123      // Thay thế toàn bộ người dùng
PATCH /users/123    // Cập nhật một phần người dùng
DELETE /users/123   // Xóa người dùng

API “Chỉ POST Mọi Thứ”:

POST /api/getUser
POST /api/createUser
POST /api/updateUser
POST /api/deleteUser

API hỗn hợp lộn xộn:

GET /users/123        // Đôi khi dùng được
POST /users/login     // Hợp lý
GET /users/delete/123 // Rất khó hiểu

Thực tế: REST không được triển khai thống nhất, gây khó hiểu và phức tạp cho dự án.

Các Ứng Dụng Hiện Đại Xử Lý Định Tuyến Riêng

Ngày nay, với React, Vue, Angular, Flutter, React Native hay Electron,... hầu hết logic định tuyến được xử lý ở phía frontend hoặc app, không còn dựa vào HTTP routes:

React/Vue/Angular: Dùng React Router, Vue Router để điều hướng client-side.

Flutter/React Native: Navigation có sẵn, không cần HTML.

Apps Mobile: API chỉ để lấy dữ liệu, không render trang.

Electron: Chỉ cần endpoints dữ liệu.

Điều này biến backend thành một “data API” đơn thuần, không cần quan tâm đến tài nguyên HTML hay điều hướng server.

Backend Thực Sự Cần Gì?

Bạn chỉ cần một số endpoint POST đơn giản để lấy hoặc thay đổi dữ liệu:

Ứng dụng	Endpoint	Chức năng
React	POST /api/users	Lấy dữ liệu người dùng
Flutter	POST /api/products	Lấy danh sách sản phẩm
Mobile	POST /api/auth	Đăng nhập
Dashboard	POST /api/analytics	Biểu đồ báo cáo

Ngoài ra, GET chỉ cần thiết cho:

Tài nguyên tĩnh như CSS, JS, hình ảnh

Trang SEO (nếu có)

Kiểm tra tình trạng hệ thống

Bạn không cần PUT, PATCH hay DELETE khi backend chỉ giữ vai trò trả dữ liệu theo yêu cầu.

Tại Sao PUT/PATCH/DELETE Chỉ Là Buổi Biểu Diễn?

REST Đưa Câu Hỏi Phức Tạp Không Cần Thiết

Phép toán có idempotent hay không?

Là thay thế toàn bộ (PUT) hay cập nhật từng phần (PATCH)?

DELETE có nên trả lại dữ liệu đã xóa không?

Trong hầu hết trường hợp, code chỉ cần biết rõ hành động và tham số mà API nhận – sự phân biệt HTTP này là phiền toái.

Bạn có thể làm rõ ý định bằng trường dữ liệu “action” thay vì dùng phương thức HTTP:

# Thay vì PUT /users/123
action = "replace_user"
id = 123
name = "John Doe"
email = "[email protected]"

# Thay vì PATCH /users/123
action = "update_user"
id = 123
email = "[email protected]"

# Thay vì DELETE /users/123
action = "delete_user"
id = 123

Ý định rõ ràng, không phải nhớ quá nhiều quy tắc về HTTP.

TOML: Người Thay Thế JSON Đáng Giá

Vấn Đề Với JSON

JSON thường hay gây ra:

Nhiều dấu nháy phức tạp

Khó đọc với cấu trúc lồng nhau

Không hỗ trợ comment

Ví dụ JSON:

{
  "user": {
    "name": "John Doe",
    "preferences": {
      "notifications": true,
      "theme": "dark"
    }
  }
}

Ưu Thế Của TOML

Định dạng TOML sạch đẹp hơn:

action = "create_user"

[user]
name = "John Doe"

[user.preferences]
notifications = true
theme = "dark"

Lợi ích TOML:

Dễ đọc, dễ viết hơn

Hỗ trợ bình luận

Tránh lỗi trích dẫn

Dễ phân tích hơn YAML

Tự mô tả hành động qua trường action

Giải Pháp: Chỉ Dùng GET/POST Kèm TOML

Quy Tắc Mới

GET: Dùng cho các tài nguyên do con người truy cập trực tiếp (ví dụ file tĩnh, trang SEO).

POST: Tất cả các yêu cầu API; nội dung gửi bằng TOML chứa trường action xác định rõ thao tác.

Ví dụ API:

# Lấy người dùng
POST /api/users
action = "get"
id = 123

# Tạo người dùng
action = "create"
name = "Jane Smith"
email = "[email protected]"

# Cập nhật người dùng
action = "update"
id = 456
email = "[email protected]"

# Xóa người dùng
action = "delete"
id = 789

Phản hồi:

status = "success"

[user]
name = "John Doe"
email = "[email protected]"
created_at = 2025-06-13T10:30:00Z

Cách này giúp API nhất quán, đơn giản và rõ ràng hơn nhiều so với thiết kế REST truyền thống.

Ví Dụ Thực Tế: So Sánh Với Laravel Pagination

Laravel Response Đầy Rẫy Dữ Liệu Thừa

Laravel trả về dữ liệu kèm rất nhiều metadata và dữ liệu lồng nhau:

Thành phần	Mô tả
`first_page_url` , `last_page_url`	URL không cần thiết
`links`	Mảng phân trang đa dạng
`author`	Lặp lại nhiều lần tác giả
`comments`	Tải full comment ngay từ đầu
`content`	Chuỗi nội dung dài

Phản hồi dễ lên đến chục KB, gây tốn băng thông và khó cache.

Cách Tiếp Cận TOML Với Tham Chiếu Đối Tượng

# Yêu cầu feed ban đầu
action = "get_feed"
user_id = 123
limit = 15

# Phản hồi
status = "success"
post_ids = [1, 2, 3, 4, 5, ..., 15]
author_ids = [123, 456, 789]  # Không trùng lặp
has_more = true
next_cursor = "eyJpZCI6MTUsInRpbWUiOjE2ODk="

Các phần như bài đăng, tác giả và bình luận được tải riêng theo nhu cầu.

Kết Quả So Sánh

Đặc điểm	Laravel (JSON)	TOML và hành vi tham chiếu
Kích thước phản hồi	~50 KB	~2 KB
Tải dữ liệu	Toàn bộ, nhiều trùng lặp	Chỉ tải khi cần
Chiến lược caching	Khó kiểm soát	Dễ dàng kiểm soát và cục bộ
Phù hợp UX hiện đại	Kém (đùn tải dữ liệu)	Rất phù hợp (lazy loading, infinite scroll)

Phương án TOML kết hợp load on demand giúp tăng trải nghiệm, giảm tải hệ thống và tăng hiệu suất rõ rệt.

"Nhưng Còn HTTP Semantics Thì Sao?"

REST purists sẽ tiếc nuối việc “mất đi” ý nghĩa của HTTP methods.

Tuy nhiên, trong thực tế phát triển ứng dụng năm 2025:

Semantics của HTTP không nhất quán giữa các backend

Chỉ có một ứng dụng thực sự: truyền dữ liệu qua POST

Các frontend framework quản lý định tuyến mà không cần server-side routing

Việc tranh luận về DELETE, PUT hay PATCH đang trở thành câu chuyện học thuật không cần thiết đối với nhiều dự án.

Frontend Cần Gì? Không Cần GET Routes

React Router và các thư viện tương tự xử lý đường dẫn nội bộ mà không cần server phản hồi.

Apps mobile chỉ gửi request lấy dữ liệu qua API endpoints.

Backend chỉ cần tập trung trả dữ liệu, không lo về route hay view.

Bạn có thể để frontend làm điều hướng, backend làm dữ liệu.

Lộ Trình Chuyển Đổi

Bạn không cần thay đổi toàn bộ hệ thống ngay lập tức.

Tạo API mới với POST + TOML + trường action

Giữ nguyên API cũ để không đứt quãng

Migrate frontend dần sang gọi API mới

Đơn giản hóa tài liệu hướng dẫn dùng API qua các “action”

API trở nên tự giải thích hơn, giúp developer mới dễ nắm bắt và duy trì.

Kết Luận: Giữ Cho Mọi Thứ Đơn Giản

REST đã hứa hẹn sự đơn giản, nhưng thực tế lại phức tạp và gây tranh cãi.

Ứng dụng hiện đại chỉ cần POST lấy dữ liệu, GET tài nguyên tĩnh.

TOML giúp payload dễ đọc, dễ viết và tự giải thích.

Sử dụng trường action để chỉ rõ ý định, tránh tranh cãi về phương thức HTTP.

Frontend hiện đại tự quản lý việc định tuyến, backend đóng vai trò server dữ liệu đơn giản.

Hãy dừng việc tranh luận không hồi kết về REST và HTTP verbs. Tập trung xây dựng API rõ ràng, tối giản và hiệu quả ngay hôm nay.

Bạn nghĩ sao về việc “vứt bỏ” REST truyền thống để áp dụng cách làm mới? Hãy chia sẻ ý kiến bên dưới nhé! 👇

Tham Khảo

Fielding, Roy Thomas. "Architectural Styles and the Design of Network-based Software Architectures," 2000.

JSON vs TOML Comparison, https://toml.io/en/

Modern API Design Patterns, 2024,
API_Experts

React Router Documentation, https://reactrouter.com/

Laravel Official Documentation, Pagination, https://laravel.com/docs/pagination

"Why REST Is Broken," ProgrammableWeb, November 20, 2023