Chủ Nhật, 16 tháng 8, 2026

REST API là gì? (GET, POST, PUT, DELETE nói chuyện với nhau như thế nào?)

Khi đi coi một chương trình ca nhạc hay coi san khấu kịch..Bạn sẽ thấy ca sĩ hay các nghệ sĩ đeo một cái tai nghe...

Ở bài trước.

Chúng ta vừa làm quen với CRUD:

Create → Tạo
Read → Đọc
Update → Sửa
Delete → Xóa

😄

Nhưng có một câu hỏi rất hay:

"Frontend làm sao nói chuyện với Backend để thực hiện CRUD?"

Ví dụ.

Bạn đang mở một website bán hàng.

Bạn bấm:

"Xem sản phẩm."

Frontend phải nói với Backend:

"Ê, cho tôi danh sách sản phẩm."

Khi bạn bấm:

"Thêm sản phẩm."

Frontend lại phải nói:

"Ê, lưu sản phẩm này vào Database."

Rồi:

"Sửa sản phẩm."

"Ê, sửa sản phẩm số 15."

Và:

"Xóa sản phẩm."

"Ê, xóa sản phẩm số 15."

😄

Cách các ứng dụng giao tiếp với nhau như vậy chính là nơi API và đặc biệt là REST API xuất hiện.

REST API là gì?

REST API là một cách thiết kế API dựa trên các nguyên tắc của REST (Representational State Transfer), cho phép các ứng dụng giao tiếp với nhau thông qua HTTP.

REST API thường sử dụng các HTTP method như:

GET → lấy dữ liệu
POST → tạo dữ liệu
PUT/PATCH → cập nhật dữ liệu
DELETE → xóa dữ liệu

Ví dụ:


GET    /api/products
POST   /api/products
PUT    /api/products/15
DELETE /api/products/15

REST API thường kết hợp với JSON để trao đổi dữ liệu.

Ví dụ đời thường nhất 🍔

Hãy tưởng tượng bạn bước vào một nhà hàng.

Bạn không chạy thẳng vào bếp.

🤣

Bạn ngồi ở bàn.

Gọi nhân viên:

"Cho tôi một hamburger."

Nhân viên mang order vào bếp.

Đầu bếp xử lý.

Sau đó món ăn được mang ra.

🍔

Trong câu chuyện này:

Bạn

→ Frontend.

Nhân viên phục vụ

→ API.

Nhà bếp

→ Backend.

Kho nguyên liệu

→ Database.

API chính là:

người trung gian giúp hai bên nói chuyện với nhau.

API và REST API có giống nhau không?

Không hoàn toàn.

Đây là chỗ người mới rất dễ nhầm.

😄

API là khái niệm rộng.

Nó là cách để các phần mềm giao tiếp với nhau.

Còn:

REST API

là một cách thiết kế API theo các nguyên tắc của REST và thường sử dụng HTTP.

Có thể hiểu đơn giản:

API là "nhân viên phục vụ".

REST là "bộ quy tắc phục vụ".

🤣

REST API nói chuyện bằng gì?

Thông thường:

HTTP.

Chính là thứ chúng ta đã học ở bài HTTP vs HTTPS.

Ví dụ:


GET https://example.com/api/products

Ở đây:

GET

là HTTP method.

Còn:


/api/products

là endpoint.

Endpoint là gì?

Endpoint có thể hiểu đơn giản là:

Địa chỉ mà API cung cấp để thực hiện một chức năng nào đó.

Ví dụ:


/api/products

→ Làm việc với danh sách sản phẩm.


/api/users

→ Làm việc với người dùng.


/api/orders

→ Làm việc với đơn hàng.

GET là gì? 👀

GET thường dùng để:

"Cho tôi xem dữ liệu."

Ví dụ:


GET /api/products

Bạn đang nói:

"Cho tôi danh sách sản phẩm."

Backend có thể trả về:


[
  {
    "id": 1,
    "name": "iPhone",
    "price": 999
  },
  {
    "id": 2,
    "name": "Samsung",
    "price": 799
  }
]

Đây chính là:

Read trong CRUD.

POST là gì? ➕

POST thường dùng để:

"Tạo dữ liệu mới."

Ví dụ:


POST /api/products

Frontend gửi:


{
  "name": "Laptop",
  "price": 1200
}

Backend nhận.

↓

Kiểm tra dữ liệu.

↓

Lưu vào Database.

↓

Trả kết quả.

Ví dụ:


{
  "id": 3,
  "name": "Laptop",
  "price": 1200
}

Đây là:

Create.

PUT là gì? ✏️

PUT thường được dùng để cập nhật một resource.

Ví dụ:


PUT /api/products/3

Có nghĩa:

"Tôi muốn cập nhật sản phẩm số 3."

Frontend gửi:


{
  "name": "Laptop Pro",
  "price": 1500
}

Backend cập nhật Database.

Đây là:

Update.

PATCH thì sao?

Bạn sẽ gặp:


PATCH /api/products/3

PATCH cũng dùng để cập nhật.

Điểm khác đơn giản có thể hiểu như sau:

PUT

→ thường được dùng để cập nhật toàn bộ resource.

PATCH

→ thường dùng để cập nhật một phần.

Ví dụ sản phẩm đang là:


{
  "name": "Laptop",
  "price": 1200,
  "stock": 10
}

Bạn chỉ muốn đổi giá.

PATCH có thể gửi:


{
  "price": 1100
}

Không cần gửi lại tất cả thông tin.

DELETE là gì? 🗑️

Tên nói lên tất cả.

🤣

DELETE dùng để xóa resource.

Ví dụ:


DELETE /api/products/3

Backend hiểu:

"Xóa sản phẩm số 3."

↓

Database xóa dữ liệu.

↓

Backend trả kết quả.

Ví dụ:


{
  "message": "Product deleted successfully"
}

Đây là:

Delete.

Nhìn CRUD và REST cạnh nhau 😎

Đây là bảng cực kỳ đáng nhớ:

CRUD	HTTP Method	Ví dụ
Create	POST	`/api/products`
Read	GET	`/api/products`
Update	PUT/PATCH	`/api/products/3`
Delete	DELETE	`/api/products/3`

Chỉ cần nhớ bảng này.

Bạn đã hiểu một phần rất lớn của REST API.

Tại sao GET và POST khác nhau?

Đây cũng là câu hỏi người mới thường gặp.

Ví dụ:


GET /api/products

Bạn đang:

"Cho tôi dữ liệu."

Còn:


POST /api/products

Bạn đang:

"Tôi muốn tạo dữ liệu."

Một bên:

Lấy.

Một bên:

Gửi để tạo.

😄

REST API hoạt động như thế nào?

Hãy đi từng bước.

Bạn mở app bán hàng.

↓

Bấm:

Xem sản phẩm

↓

Frontend gửi:


GET /api/products

↓

Backend nhận.

↓

Backend hỏi Database:


SELECT * FROM products;

↓

Database trả dữ liệu.

↓

Backend chuyển dữ liệu thành JSON.

↓

Frontend nhận JSON.

↓

Frontend hiển thị sản phẩm.

🎉

Toàn bộ quá trình có thể hình dung:


Frontend
   ↓
HTTP Request
   ↓
REST API
   ↓
Backend
   ↓
Database
   ↑
Backend
   ↑
JSON Response
   ↑
REST API
   ↑
Frontend

Request và Response là gì?

REST API thường có hai thứ:

Request

và

Response.

Request 📤

Request là:

"Tôi muốn gì?"

Ví dụ:


GET /api/products

Response 📥

Response là:

"Đây là kết quả."

Ví dụ:


[
  {
    "id": 1,
    "name": "iPhone"
  }
]

Rất đơn giản.

Bạn hỏi.

API trả lời.

😄

Status Code cũng rất quan trọng 🚦

API không chỉ trả JSON.

Nó còn trả:

HTTP Status Code.

Ví dụ:

→ Thành công.

→ Đã tạo dữ liệu thành công.

→ Request không hợp lệ.

→ Chưa xác thực.

→ Không có quyền.

→ Không tìm thấy.

→ Server gặp lỗi.

Ví dụ thực tế

Bạn gọi:


GET /api/products/999

Nhưng sản phẩm 999 không tồn tại.

Backend có thể trả:


404 Not Found

kèm:


{
  "message": "Product not found"
}

Frontend nhìn vào.

À.

Không có sản phẩm.

😄

Hiển thị:

"Không tìm thấy sản phẩm."

"Chua thêm" 😆

REST API thực ra giống như gọi đồ ăn.

Bạn nói:

"Cho tôi một hamburger."

🍔

API:

"Dạ."

Backend:

"Đầu bếp! Một hamburger!"

Đầu bếp:

"Có ngay!"

Database:

"Đây là thịt."

🤣

Cuối cùng API quay lại:

"Đây ạ."

Nếu hết món:

"Xin lỗi, món này không có."

→ 404

Nếu bạn chưa trả tiền:

"Anh/chị chưa đăng nhập."

→ 401

Nếu bạn không được phép gọi món đặc biệt:

"Anh/chị không có quyền."

→ 403

Nếu nhà bếp cháy:

🔥

"Xin lỗi, hệ thống đang gặp sự cố."

→ 500

😆

Nhìn REST API như vậy.

Tự nhiên dễ hiểu hơn rất nhiều.

REST API và JSON 📦

Ở bài 59.

Chúng ta đã nói về JSON.

Bây giờ hai bài gặp nhau.

😄

Frontend gửi:


{
  "name": "Laptop",
  "price": 1200
}

Backend xử lý.

↓

Backend trả:


{
  "id": 10,
  "name": "Laptop",
  "price": 1200
}

JSON rất phổ biến trong API vì nó nhẹ.

Dễ đọc.

Dễ xử lý.

Và hầu hết ngôn ngữ lập trình hiện đại đều hỗ trợ tốt.

REST API có phải chỉ dành cho Website?

Không.

😄

Đây mới là phần thú vị.

API có thể kết nối:

Website ↔ Server

Mobile App ↔ Server

Desktop App ↔ Server

Website ↔ Website

Hệ thống A ↔ Hệ thống B

Ví dụ.

Bạn dùng ứng dụng điện thoại.

App không nhất thiết lưu toàn bộ dữ liệu ngay trên điện thoại.

Nó có thể gọi:


GET /api/products

↓

Server trả JSON.

↓

App hiển thị.

Ví dụ "vô cùng" thực tế 📱

Bạn mở app ngân hàng.

Muốn xem số dư.

App gửi request:


GET /api/account/balance

Server kiểm tra.

↓

Database.

↓

Trả:


{
  "balance": 1250000
}

App hiển thị:

Số dư: 1.250.000đ

Bạn không nhìn thấy API.

Nhưng rất có thể.

API đang chạy phía sau.

REST API và Authentication 🔐

Một API thực tế thường không cho ai muốn gọi cũng được.

Ví dụ:


GET /api/profile

Server có thể yêu cầu:

Token.

Ví dụ:


Authorization: Bearer abc123...

Server kiểm tra:

"Token này là của ai?"

↓

Có hợp lệ không?

↓

Có quyền xem dữ liệu không?

↓

Nếu OK.

Trả JSON.

Nếu không.

Có thể trả:


401 Unauthorized

Đây là lý do:

API + Authentication

là một chủ đề rất quan trọng khi làm Backend.

Một lỗi rất hay gặp 😭

Bạn gọi:


GET /api/products

Nhưng nhận:


404 Not Found

Bạn nghĩ:

"API hỏng."

Chưa chắc.

Có thể endpoint thật là:


/api/product

hoặc:


/api/v1/products

hoặc:


/api/products/list

😄

API không đoán được ý bạn.

Gõ sai endpoint.

→ Sai.

Debug REST API kiểu dev thật 😎

Khi API không chạy.

Đừng hoảng.

Hãy kiểm tra từng tầng.

1. URL có đúng không?


/api/products

Hay:


/api/product

2. HTTP method có đúng không?

Bạn đang dùng:

GET

nhưng API yêu cầu:


POST

→ Không chạy như mong đợi.

3. Request body có đúng không?

Ví dụ API cần:


{
  "name": "Laptop",
  "price": 1200
}

Nhưng bạn gửi:


{
  "product_name": "Laptop"
}

Backend có thể không nhận được dữ liệu cần thiết.

4. Authentication có đúng không?

Kiểm tra:


Authorization

Token.

Session.

Cookie.

...

5. Status Code là gì?

Đừng chỉ nhìn:

"Không chạy."

Hãy nhìn:


400?
401?
403?
404?
500?

Status Code thường cho bạn manh mối rất lớn.

6. Response trả gì?

Có thể API đã chạy.

Nhưng trả:


{
  "error": "Invalid email"
}

Vậy vấn đề không phải API chết.

Mà:

Dữ liệu gửi lên không hợp lệ.

Một mẹo cực hay 😎

Khi debug API.

Hãy mở:

Browser DevTools → Network

Bạn sẽ thấy:


Request URL
Request Method
Status Code
Request Headers
Request Payload
Response

😍

Đây gần như là:

Camera an ninh của API.

API nói:

"Tôi không biết tại sao lỗi."

Bạn mở Network:

"Để tôi xem anh vừa làm gì."

🤣

REST API có phải luôn dùng CRUD không?

Không.

CRUD rất phổ biến.

Nhưng API có thể làm nhiều việc khác.

Ví dụ:


POST /api/login

Đăng nhập.


POST /api/logout

Đăng xuất.


POST /api/orders/15/cancel

Hủy đơn hàng.


POST /api/payment

Thanh toán.

Không phải mọi API đều đơn giản là:

GET/POST/PUT/DELETE.

REST là một phong cách thiết kế.

Thực tế các API có thể có nhiều cách triển khai khác nhau.

Checklist chuẩn không cần chỉnh 😎

FAQ nhanh

REST API có phải là Backend không?

→ Không. REST API là một cách để các ứng dụng giao tiếp với Backend hoặc các hệ thống khác.

GET có phải lúc nào cũng dùng để lấy dữ liệu không?

→ Trong thiết kế REST thông thường, GET được dùng để truy xuất dữ liệu. Tuy nhiên, API thực tế có thể được thiết kế theo nhiều cách khác nhau.

POST có phải chỉ dùng để đăng ký tài khoản?

→ Không. POST thường dùng để tạo resource mới và cũng có thể được dùng cho nhiều thao tác khác như đăng nhập, gửi form hoặc thực hiện một action.

PUT và PATCH khác nhau thế nào?

→ PUT thường được dùng để thay thế/cập nhật toàn bộ resource, còn PATCH thường dùng để cập nhật một phần resource.

API có bắt buộc phải trả JSON không?

→ Không. API có thể trả nhiều định dạng khác nhau. JSON chỉ là định dạng rất phổ biến.

REST API có khó không?

→ Ý tưởng cơ bản không khó. Cái khó bắt đầu xuất hiện khi bạn thêm Authentication, Authorization, Validation, Pagination, Rate Limiting, Error Handling và Security.

Bạn có thể cũng đang gặp 😭

👉 API là gì?

👉 JSON là gì?

👉 HTTP vs HTTPS là gì?

👉 CRUD là gì?

👉 MVC là gì? (Ai nhận order, ai nấu ăn và ai mang món ra?)

👉 Framework là gì? (Tại sao ai cũng thích dùng Laravel thay vì viết mọi thứ từ đầu?)

👉 LIMIT trong MySQL là gì?

👉 SQL Injection là gì?

👉 Prepared Statement là gì?

Tổng kết

Nếu CRUD là bốn việc bạn làm với dữ liệu:


Create
Read
Update
Delete

thì REST API là một trong những cách để các ứng dụng yêu cầu Backend thực hiện những việc đó.

Có thể hình dung:


Frontend
   ↓
"Cho tôi sản phẩm số 10"
   ↓
GET /api/products/10
   ↓
Backend
   ↓
Database
   ↓
Backend
   ↓
JSON
   ↓
Frontend

😄

Và bốn người bạn quan trọng:


GET       → Tôi muốn xem.

POST      → Tôi muốn tạo.

PUT/PATCH → Tôi muốn sửa.

DELETE    → Tôi muốn xóa.

Chỉ cần hiểu được bốn câu này.

Bạn đã bắt đầu đọc được rất nhiều API documentation rồi.

Và đây chính là lúc các bài trước bắt đầu nối thành một hệ thống:

Frontend

↓

HTTP

↓

REST API

↓

Backend

↓

CRUD

↓

Database

↓

JSON

↓

Frontend

🎯

Nếu chỉ nhớ một điều từ bài này, hãy nhớ:

REST API giống như một người phục vụ: Frontend gọi món bằng HTTP, Backend xử lý phía sau, rồi API mang kết quả về. 🍔