REST API & HTTP

        Trong quá trình phát triển của công nghệ thông tin, nhu cầu kết nối các ứng dụng, thiết bị và dịch vụ ngày càng trở nên quan trọng. Một ứng dụng hiện đại hiếm khi hoạt động hoàn toàn độc lập. Ứng dụng di động cần trao đổi dữ liệu với máy chủ, hệ thống thương mại điện tử phải kết nối với cổng thanh toán, còn các nền tảng doanh nghiệp cần tích hợp với nhiều dịch vụ bên ngoài. Để thực hiện những hoạt động đó, các hệ thống thường sử dụng HTTP làm giao thức truyền thông và REST API làm một phong cách thiết kế giao diện lập trình ứng dụng.

HTTP cung cấp các quy tắc để máy khách và máy chủ trao đổi thông tin trên mạng. Trong khi đó, REST API tổ chức các tài nguyên và thao tác trên tài nguyên theo cách đơn giản, thống nhất và dễ mở rộng. Hai khái niệm này thường đi cùng nhau, nhưng không hoàn toàn đồng nhất: HTTP là một giao thức, còn REST là một tập hợp các nguyên tắc kiến trúc. Việc hiểu rõ mối quan hệ giữa REST API và HTTP có ý nghĩa quan trọng đối với sinh viên, lập trình viên và những người thiết kế hệ thống phần mềm.

1. Tổng quan về HTTP

1.1. HTTP là gì?

HTTP, viết tắt của Hypertext Transfer Protocol, là giao thức truyền tải siêu văn bản được sử dụng để trao đổi dữ liệu giữa máy khách và máy chủ. Khi người dùng truy cập một trang web, trình duyệt đóng vai trò máy khách gửi yêu cầu đến máy chủ. Máy chủ xử lý yêu cầu rồi trả về phản hồi, thường là HTML, JSON, hình ảnh, tệp tin hoặc các loại dữ liệu khác.

Mô hình giao tiếp cơ bản của HTTP gồm hai thành phần:

• Client — máy khách: Có thể là trình duyệt web, ứng dụng di động, ứng dụng máy tính hoặc một dịch vụ khác.
• Server — máy chủ: Tiếp nhận yêu cầu, xử lý nghiệp vụ, truy cập cơ sở dữ liệu và gửi phản hồi về máy khách.

Ví dụ, khi người dùng truy cập địa chỉ https://example.com/products, trình duyệt có thể gửi một yêu cầu HTTP như sau:

GET /products HTTP/1.1
Host: example.com
Accept: application/json

Máy chủ có thể trả về: 

HTTP/1.1 200 OK
Content-Type: application/json
[
  {"id": 1, "name": "Laptop", "price": 1200},
  {"id": 2, "name": "Keyboard", "price": 80}
]

1.2. Cấu trúc của một HTTP request

Một HTTP request thường bao gồm các thành phần sau:

• Method: Xác định thao tác mà máy khách muốn thực hiện, chẳng hạn GET, POST, PUT, PATCH hoặc DELETE.
• URL hoặc URI: Xác định địa chỉ của tài nguyên.
• Headers: Chứa thông tin bổ sung như loại dữ liệu, thông tin xác thực, ngôn ngữ hoặc bộ nhớ đệm.
• Body: Chứa dữ liệu gửi lên máy chủ, thường xuất hiện trong các yêu cầu POST, PUT hoặc PATCH.

Ví dụ:

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer <token>
{
  "name": "Nguyen Van A",
  "email": "[email protected]"
}

1.3. Cấu trúc của HTTP response

HTTP response thường gồm:

• Status code: Mã trạng thái cho biết kết quả xử lý.
• Headers: Mô tả thông tin về phản hồi.
• Body: Dữ liệu mà máy chủ trả về.

Một số mã trạng thái phổ biến:

Mã	Ý nghĩa	Ví dụ sử dụng
200 OK	Yêu cầu thành công	Lấy dữ liệu thành công
201 Created	Tạo tài nguyên thành công	Tạo người dùng mới
204 No Content	Thành công nhưng không có nội dung trả về	Xóa tài nguyên
400 Bad Request	Dữ liệu yêu cầu không hợp lệ	Thiếu trường bắt buộc
401 Unauthorized	Chưa xác thực hoặc xác thực không hợp lệ	Thiếu token
403 Forbidden	Không có quyền thực hiện	Người dùng thường truy cập chức năng quản trị
404 Not Found	Không tìm thấy tài nguyên	ID không tồn tại
409 Conflict	Xung đột dữ liệu	Email đã được đăng ký
500 Internal Server Error	Lỗi phía máy chủ	Lỗi xử lý ngoài dự kiến

 

1.4. HTTP và HTTPS

HTTP truyền dữ liệu dưới dạng không mã hóa, do đó có thể bị đọc hoặc thay đổi nếu đường truyền không an toàn. HTTPS là HTTP kết hợp với TLS, giúp mã hóa dữ liệu giữa máy khách và máy chủ. HTTPS thường được sử dụng để bảo vệ mật khẩu, token, thông tin cá nhân và dữ liệu giao dịch.

Trong thực tế, một REST API công khai nên sử dụng HTTPS thay vì HTTP thuần túy. Đây không chỉ là yêu cầu bảo mật mà còn là tiêu chuẩn phổ biến của các trình duyệt, nền tảng thanh toán và dịch vụ đám mây hiện nay.

2. REST API là gì?

2.1. Khái niệm API

API, viết tắt của Application Programming Interface, là giao diện cho phép các phần mềm giao tiếp với nhau. API quy định cách một ứng dụng có thể yêu cầu dữ liệu hoặc chức năng từ một ứng dụng khác.

Ví dụ, một ứng dụng thời tiết có thể gọi API của nhà cung cấp dữ liệu để lấy nhiệt độ hiện tại. Ứng dụng không cần biết toàn bộ cách nhà cung cấp thu thập dữ liệu; nó chỉ cần gửi yêu cầu đúng định dạng và xử lý phản hồi nhận được.

2.2. REST là gì?

REST, viết tắt của Representational State Transfer, là một phong cách kiến trúc do Roy Fielding đề xuất trong luận án tiến sĩ năm 2000. REST không phải là một ngôn ngữ lập trình hay một thư viện cụ thể. Đây là tập hợp các nguyên tắc dùng để thiết kế hệ thống phân tán, đặc biệt là các dịch vụ web.

Một API được gọi là RESTful khi nó tuân thủ tương đối đầy đủ các nguyên tắc của REST. Trong đó, các đối tượng nghiệp vụ được biểu diễn dưới dạng tài nguyên (resource), chẳng hạn:

• Người dùng: /users
• Một người dùng cụ thể: /users/123
• Sản phẩm: /products
• Đơn hàng: /orders

Mỗi tài nguyên được định danh bằng một URI và được thao tác thông qua các phương thức HTTP.

3. Các nguyên tắc cốt lõi của REST

3.1. Client–Server

REST tách biệt trách nhiệm giữa máy khách và máy chủ. Máy khách chịu trách nhiệm về giao diện và trải nghiệm người dùng, còn máy chủ chịu trách nhiệm về dữ liệu và logic nghiệp vụ.

Sự tách biệt này giúp hai phía có thể phát triển độc lập. Ví dụ, đội ngũ phát triển ứng dụng Android có thể thay đổi giao diện mà không cần sửa toàn bộ hệ thống máy chủ, miễn là hợp đồng API vẫn được duy trì.

3.2. Stateless

Mỗi request phải chứa đầy đủ thông tin cần thiết để máy chủ xử lý. Máy chủ không nên phụ thuộc vào trạng thái phiên được lưu giữa các request của máy khách.

Ví dụ, thay vì dựa vào session trên máy chủ, client có thể gửi access token trong header:

Authorization: Bearer eyJhbGciOi...

Tính chất stateless giúp hệ thống dễ mở rộng theo chiều ngang vì bất kỳ máy chủ nào trong cụm cũng có thể xử lý request.

3.3. Cacheable

Phản hồi cần cho biết dữ liệu có thể được lưu vào bộ nhớ đệm hay không. Caching giúp giảm số lượng request gửi đến máy chủ và cải thiện hiệu suất.

Một số header liên quan đến caching gồm:

Cache-Control: max-age=3600
ETag: "abc123"

Tuy nhiên, dữ liệu nhạy cảm hoặc dữ liệu thay đổi liên tục cần được cấu hình cache cẩn thận để tránh trả về thông tin cũ hoặc lộ dữ liệu.

3.4. Uniform Interface

REST nhấn mạnh một giao diện thống nhất giữa các thành phần. Điều này thể hiện qua việc:

• Tài nguyên được định danh bằng URI.
• Tài nguyên được biểu diễn bằng định dạng như JSON hoặc XML.
• Các thao tác sử dụng phương thức HTTP có ý nghĩa rõ ràng.
• Thông điệp chứa đủ thông tin để bên nhận hiểu và xử lý.

Giao diện thống nhất làm giảm sự phụ thuộc giữa client và server, đồng thời giúp API dễ học và dễ sử dụng.

3.5. Layered System

Client không nhất thiết phải biết request được xử lý trực tiếp bởi máy chủ ứng dụng hay qua proxy, gateway, load balancer và cache trung gian. Mỗi lớp có thể đảm nhận một vai trò riêng mà không làm thay đổi cách client sử dụng API.

Kiến trúc phân lớp hỗ trợ các yêu cầu như cân bằng tải, bảo mật, giám sát và tối ưu hiệu năng.

3.6. Code on Demand

Đây là nguyên tắc tùy chọn. Máy chủ có thể gửi mã thực thi cho client, chẳng hạn JavaScript, để mở rộng chức năng của client. Trong các REST API hiện đại, nguyên tắc này ít được sử dụng hơn so với các nguyên tắc còn lại.

4. HTTP methods trong REST API

4.1. GET — đọc dữ liệu

GET được sử dụng để lấy một hoặc nhiều tài nguyên.

GET /api/products
GET /api/products/42

GET nên là phương thức safe, nghĩa là việc gọi request không làm thay đổi dữ liệu trên máy chủ. Nó cũng thường được xem là idempotent: gọi nhiều lần cho cùng một trạng thái ban đầu sẽ cho kết quả tương đương.

4.2. POST — tạo tài nguyên hoặc thực hiện hành động

POST thường được dùng để tạo tài nguyên mới:

POST /api/products
Content-Type: application/json
{
  "name": "Monitor",
  "price": 300
}

Nếu thành công, máy chủ nên trả về mã 201 Created và có thể kèm theo tài nguyên vừa tạo.

4.3. PUT — thay thế toàn bộ tài nguyên

PUT thường biểu diễn việc cập nhật hoặc thay thế toàn bộ tài nguyên:

PUT /api/products/42
Content-Type: application/json
{
  "name": "Monitor Pro",
  "price": 350
}

PUT thường có tính idempotent. Nghĩa là gửi cùng một request nhiều lần không nên tạo ra nhiều tài nguyên khác nhau.

4.4. PATCH — cập nhật một phần tài nguyên

PATCH dùng khi chỉ cần thay đổi một số trường:

PATCH /api/products/42
Content-Type: application/json
{
  "price": 330
}

So với PUT, PATCH phù hợp hơn khi tài nguyên có nhiều trường nhưng client chỉ muốn chỉnh sửa một phần nhỏ.

4.5. DELETE — xóa tài nguyên

DELETE được sử dụng để xóa tài nguyên:

DELETE /api/products/42

Phản hồi có thể là 204 No Content nếu xóa thành công và không cần gửi nội dung bổ sung.

5. Thiết kế endpoint REST API

Một API tốt cần có quy ước nhất quán về URL, dữ liệu và lỗi. Một số nguyên tắc thường được áp dụng như sau.

5.1. Dùng danh từ thay vì động từ

Nên viết:

GET /users
GET /users/10/orders

Thay vì:

GET /getUsers
POST /createOrder

HTTP method đã thể hiện hành động, vì vậy URL nên tập trung mô tả tài nguyên.

5.2. Sử dụng số nhiều nhất quán

Thông thường, tài nguyên dạng collection được đặt ở dạng số nhiều:

/products
/orders
/customers

Cách đặt tên nhất quán làm API dễ dự đoán hơn.

5.3. Biểu diễn quan hệ giữa tài nguyên

Nếu cần truy vấn các đơn hàng của một người dùng, có thể dùng:

GET /users/10/orders

Tuy nhiên, không nên tạo URL lồng quá sâu vì sẽ khó sử dụng. Trong nhiều trường hợp, bộ lọc query cũng là lựa chọn phù hợp:

GET /orders?user_id=10

5.4. Lọc, sắp xếp và phân trang

Đối với tập dữ liệu lớn, API nên hỗ trợ các tham số:

GET /products?page=2&limit=20&sort=-price&category=books

Phân trang giúp giảm kích thước phản hồi và giảm tải cho cả client lẫn server. Phản hồi có thể bao gồm thông tin tổng quát:

{
  "data": [
    { "id": 1, "name": "Book A" }
  ],
  "pagination": {
    "page": 2,
    "limit": 20,
    "total": 145,
    "total_pages": 8
  }
}

6. Định dạng dữ liệu và xử lý lỗi

6.1. JSON

JSON là định dạng phổ biến nhất trong REST API vì dễ đọc, nhỏ gọn và được hỗ trợ bởi hầu hết ngôn ngữ lập trình.

Ví dụ:

{
  "id": 101,
  "name": "Tran Thi B",
  "email": "[email protected]",
  "active": true
}

API nên xác định rõ loại dữ liệu qua header Content-Type, chẳng hạn:

Content-Type: application/json

6.2. Cấu trúc lỗi nhất quán

Thông báo lỗi cần có cấu trúc rõ ràng để client có thể xử lý tự động:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Dữ liệu không hợp lệ",
    "details": [
      {
        "field": "email",
        "message": "Email không đúng định dạng"
      }
    ],
    "request_id": "req_123456"
  }
}

Không nên trả về thông báo lỗi quá chung chung như “Something went wrong” trong mọi trường hợp, nhưng cũng không nên tiết lộ stack trace hoặc thông tin nội bộ cho người dùng cuối.

7. Xác thực và bảo mật REST API

7.1. Authentication và Authorization

• Authentication xác định người gọi API là ai.
• Authorization xác định người đó được phép thực hiện thao tác nào.

Một phương thức phổ biến là sử dụng token trong header Authorization:

Authorization: Bearer <access-token>

Token có thể là JWT hoặc một dạng access token khác. Hệ thống cần bảo vệ khóa bí mật, đặt thời hạn token hợp lý và hỗ trợ thu hồi token khi cần.

7.2. Các biện pháp bảo mật cơ bản

Một REST API nên áp dụng các biện pháp sau:

• Luôn sử dụng HTTPS.
• Kiểm tra và xác thực toàn bộ dữ liệu đầu vào.
• Phân quyền ở phía máy chủ, không chỉ dựa vào giao diện client.
• Giới hạn số lần request bằng rate limiting.
• Không trả về dữ liệu nhạy cảm không cần thiết.
• Ghi log các sự kiện quan trọng nhưng tránh ghi mật khẩu hoặc token.
• Sử dụng CORS đúng cấu hình.
• Áp dụng các biện pháp chống tấn công như SQL injection, XSS và CSRF khi phù hợp.

8. Ưu điểm của REST API

REST API có nhiều ưu điểm khiến nó trở thành lựa chọn phổ biến.

8.1. Đơn giản và dễ tiếp cận

REST tận dụng các khái niệm quen thuộc của HTTP như URL, method, header và status code. Lập trình viên có thể kiểm thử API bằng trình duyệt, cURL hoặc các công cụ như Postman

8.2. Khả năng mở rộng

Tính stateless và kiến trúc phân lớp giúp REST API phù hợp với hệ thống phân tán và môi trường cloud. Nhiều máy chủ có thể cùng xử lý request mà không cần chia sẻ trạng thái phiên phức tạp.

8.3. Hỗ trợ nhiều loại client

Một REST API có thể được sử dụng bởi website, ứng dụng iOS, Android, phần mềm máy tính hoặc dịch vụ tích hợp của đối tác. Điều này thúc đẩy việc tái sử dụng logic nghiệp vụ.

8.4. Tách biệt frontend và backend

Frontend có thể được xây dựng bằng React, Vue, Angular hoặc ứng dụng di động, trong khi backend được phát triển bằng Java, Python, Go, Node.js hay các công nghệ khác. Hai bên giao tiếp thông qua hợp đồng API.

9. Hạn chế của REST API

Mặc dù phổ biến, REST không phải giải pháp hoàn hảo cho mọi trường hợp.

9.1. Over-fetching và under-fetching

Client đôi khi nhận nhiều dữ liệu hơn nhu cầu hoặc phải gọi nhiều endpoint để lấy đủ thông tin. Ví dụ, một màn hình cần thông tin người dùng cùng danh sách đơn hàng nhưng phải gọi nhiều API riêng biệt.

9.2. Quản lý phiên bản

Khi API thay đổi, hệ thống cần duy trì khả năng tương thích với client cũ. Một số cách phổ biến là:

/api/v1/products
/api/v2/products

Ngoài việc đánh số phiên bản trong URL, có thể dùng header hoặc cơ chế thương lượng nội dung. Quan trọng nhất là phải có chính sách deprecate và thông báo rõ ràng.

9.3. Tính linh hoạt có giới hạn

REST thường tổ chức dữ liệu theo tài nguyên và endpoint cố định. Với các truy vấn phức tạp, GraphQL hoặc các giao thức chuyên biệt có thể phù hợp hơn.

10. REST API so với một số mô hình khác

10.1. REST và SOAP

SOAP là một giao thức có quy tắc chặt chẽ, thường sử dụng XML và hỗ trợ nhiều tiêu chuẩn doanh nghiệp. REST nhẹ hơn, linh hoạt hơn và thường dùng JSON. SOAP vẫn có thể phù hợp với các hệ thống yêu cầu hợp đồng nghiêm ngặt, giao dịch phức tạp hoặc tiêu chuẩn bảo mật đặc thù.

10.2. REST và GraphQL

REST sử dụng nhiều endpoint, còn GraphQL thường cung cấp một endpoint để client mô tả chính xác dữ liệu cần lấy. GraphQL giải quyết tốt vấn đề over-fetching nhưng đòi hỏi cách thiết kế, caching và bảo mật khác.

10.3. REST và gRPC

gRPC thường dùng Protocol Buffers và HTTP/2, phù hợp cho giao tiếp hiệu năng cao giữa các dịch vụ nội bộ. REST dễ tiếp cận hơn đối với client công khai và các hệ thống cần tương tác trực tiếp qua web.

11. Quy trình xây dựng một REST API chất lượng

Một quy trình phát triển API có thể gồm các bước sau:

• Xác định yêu cầu nghiệp vụ: Làm rõ tài nguyên, thao tác, người dùng và quyền truy cập.
• Thiết kế hợp đồng API: Quy định endpoint, method, request, response, status code và lỗi.
• Chọn mô hình dữ liệu: Thiết kế cơ sở dữ liệu và quan hệ giữa các tài nguyên.
• Triển khai logic nghiệp vụ: Tách lớp controller, service và repository nếu phù hợp.
• Thêm xác thực và phân quyền: Bảo vệ endpoint theo vai trò và quyền hạn.
• Kiểm thử: Kiểm thử đơn vị, tích hợp, kiểm thử lỗi và kiểm thử bảo mật.
• Tài liệu hóa: Sử dụng OpenAPI/Swagger để mô tả cách gọi API.
• Giám sát và vận hành: Theo dõi log, thời gian phản hồi, tỷ lệ lỗi và lưu lượng.
• Quản lý thay đổi: Định nghĩa phiên bản, chính sách tương thích và thời điểm ngừng hỗ trợ.

12. Ví dụ thiết kế API quản lý thư viện

Giả sử cần xây dựng API cho hệ thống thư viện. Một số endpoint có thể là:

Method	Endpoint	Ý nghĩa
GET	/books	Lấy danh sách sách
GET	/books/15	Lấy thông tin sách có ID 15
POST	/books	Thêm sách mới
PATCH	/books/15	Cập nhật một phần thông tin sách
DELETE	/books/15	Xóa sách
GET	/members/7/borrowings	Xem lịch sử mượn sách của thành viên
POST	/borrowings	Tạo phiếu mượn
PATCH	/borrowings/22/return	Đánh dấu đã trả sách

 

Một request tạo sách:

POST /api/v1/books HTTP/1.1
Host: library.example.com
Content-Type: application/json
Authorization: Bearer <token>
{
  "title": "Nhập môn lập trình",
  "author": "Nguyen Van C",
  "published_year": 2025,
  "quantity": 10
}

Phản hồi thành công:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/v1/books/15
{
  "id": 15,
  "title": "Nhập môn lập trình",
  "author": "Nguyen Van C",
  "published_year": 2025,
  "quantity": 10
}

Ví dụ này cho thấy REST API không chỉ là việc đặt tên URL. Một thiết kế tốt còn phải thể hiện rõ ngữ nghĩa của method, mã trạng thái, định dạng dữ liệu, quyền truy cập và cách xử lý lỗi.

Kết luận

REST API và HTTP là hai nền tảng quan trọng trong việc xây dựng các hệ thống phần mềm có khả năng giao tiếp qua mạng. HTTP định nghĩa cách máy khách và máy chủ gửi request, nhận response, biểu diễn trạng thái và trao đổi dữ liệu. REST cung cấp các nguyên tắc giúp tổ chức những tương tác đó quanh các tài nguyên, từ đó tạo ra API đơn giản, nhất quán và dễ mở rộng.

Một REST API chất lượng cần tận dụng đúng ý nghĩa của các HTTP method, sử dụng status code phù hợp, tổ chức endpoint rõ ràng, hỗ trợ phân trang và lọc dữ liệu, xử lý lỗi nhất quán, đồng thời bảo đảm authentication, authorization và bảo mật đường truyền. Bên cạnh các ưu điểm như tính đơn giản, khả năng mở rộng và hỗ trợ nhiều loại client, REST cũng có những hạn chế như over-fetching, vấn đề quản lý phiên bản và sự thiếu linh hoạt trong các truy vấn phức tạp.

Trong tương lai, REST vẫn sẽ giữ vai trò quan trọng, dù các mô hình như GraphQL, gRPC và event-driven architecture ngày càng phổ biến. Việc lựa chọn REST hay một mô hình khác cần dựa trên yêu cầu về hiệu năng, tính linh hoạt, khả năng tương thích, bảo mật và đặc điểm của hệ thống. Quan trọng nhất không phải là sử dụng một công nghệ theo xu hướng, mà là thiết kế giao diện giao tiếp rõ ràng, ổn định và phù hợp với nhu cầu thực tế.