Khi mở một ứng dụng đặt đồ ăn, bạn có thể xem danh sách món, đăng nhập, đặt hàng và theo dõi trạng thái giao hàng. Giao diện trên điện thoại không tự chứa toàn bộ thông tin này. Nó phải gửi yêu cầu đến một hệ thống phía sau để lấy dữ liệu và thực hiện nghiệp vụ. Thành phần giúp hai phía trao đổi với nhau thường được gọi là API.
REST API xuất hiện trong phần lớn lộ trình học Web và Mobile. Tuy nhiên, người mới thường chỉ nhớ cách gọi một đường dẫn bằng fetch, Retrofit hoặc thư viện HTTP mà chưa hiểu dữ liệu đi đâu, server xử lý gì và vì sao lại có các mã như 200, 404 hay 500.
Bài viết này giải thích REST API theo hướng có hệ thống: bắt đầu từ mô hình client–server, sau đó đi vào tài nguyên, endpoint, HTTP method, status code và JSON. Mục tiêu không phải học thuộc thuật ngữ mà là hiểu một yêu cầu đi qua hệ thống như thế nào.
API là gì?
API là viết tắt của Application Programming Interface, có thể hiểu là giao diện cho phép các phần mềm trao đổi chức năng hoặc dữ liệu theo một quy ước đã thống nhất.
Hãy hình dung một ứng dụng bán hàng gồm ba phần:
- Ứng dụng Web hoặc Mobile mà người dùng trực tiếp thao tác.
- Server xử lý đăng nhập, đơn hàng, thanh toán và các quy tắc nghiệp vụ.
- Cơ sở dữ liệu lưu người dùng, sản phẩm và lịch sử giao dịch.
Ứng dụng phía người dùng không nên truy cập trực tiếp vào cơ sở dữ liệu. Thay vào đó, nó gửi yêu cầu đến API. API tiếp nhận yêu cầu, chuyển cho logic phía server xử lý, sau đó trả về một phản hồi có cấu trúc.
API vì thế vừa là điểm giao tiếp, vừa là một hợp đồng kỹ thuật. Hợp đồng này quy định đường dẫn nào được sử dụng, dữ liệu đầu vào gồm gì, kết quả trả về có cấu trúc ra sao và lỗi được biểu diễn như thế nào.
REST API là gì?
REST là viết tắt của Representational State Transfer. Đây là một phong cách kiến trúc cho hệ thống phân tán trên mạng, được Roy Fielding trình bày trong luận án tiến sĩ năm 2000.
Trong cách tiếp cận REST, hệ thống được tổ chức quanh các tài nguyên. Tài nguyên có thể là người dùng, sản phẩm, bài viết hoặc đơn hàng. Mỗi tài nguyên được nhận diện bằng một URI và được trao đổi thông qua một dạng biểu diễn, thường là JSON trong các ứng dụng hiện đại.
Ví dụ:
GET /api/products/125
Đường dẫn trên có thể được hiểu là yêu cầu lấy tài nguyên sản phẩm có mã 125.
Một điểm cần nói rõ: không phải cứ dùng HTTP và trả về JSON thì API tự động trở thành REST đúng nghĩa. REST còn gắn với các ràng buộc kiến trúc như client–server, stateless, cache, giao diện thống nhất và hệ thống phân lớp. Trong thực tế, nhiều đội phát triển dùng cụm “REST API” theo nghĩa rộng để chỉ các API tổ chức theo tài nguyên và sử dụng HTTP tương đối nhất quán.
Những khái niệm nền tảng trong REST API
Tài nguyên
Tài nguyên là đối tượng mà hệ thống muốn quản lý hoặc cung cấp. Với website bán hàng, tài nguyên có thể gồm:
- products: sản phẩm.
- users: người dùng.
- orders: đơn hàng.
- reviews: đánh giá.
Tài nguyên không nhất thiết trùng hoàn toàn với một bảng trong cơ sở dữ liệu. Một tài nguyên API có thể được tổng hợp từ nhiều bảng hoặc nhiều dịch vụ khác nhau.
Endpoint
Endpoint là một địa chỉ cụ thể mà client có thể gửi yêu cầu đến. Ví dụ:
Endpoint tốt thường dùng danh từ để biểu diễn tài nguyên. Hành động được thể hiện bằng phương thức HTTP thay vì nhét động từ tùy ý vào đường dẫn.
Representation
Client và server không truyền “đối tượng” theo đúng dạng tồn tại trong bộ nhớ. Hai bên trao đổi một dạng biểu diễn của tài nguyên. JSON được dùng phổ biến vì gọn, dễ đọc và được hỗ trợ trên hầu hết nền tảng.
Ví dụ phản hồi sản phẩm:
HTTP request gồm những gì?
Một HTTP request thường có bốn thành phần đáng chú ý.
Method
Method mô tả ý nghĩa của thao tác. Các phương thức thường gặp gồm:
- GET: lấy biểu diễn của tài nguyên.
- POST: gửi dữ liệu để tạo mới hoặc yêu cầu server xử lý một tác vụ.
- PUT: thay thế trạng thái của tài nguyên tại URI xác định.
- PATCH: cập nhật một phần tài nguyên.
- DELETE: yêu cầu xóa tài nguyên.
Không nên hiểu máy móc rằng mọi API đều bắt buộc ánh xạ CRUD theo một công thức duy nhất. Điều quan trọng hơn là ý nghĩa của method, tài nguyên và phản hồi phải nhất quán trong toàn hệ thống.
URI
URI xác định tài nguyên mục tiêu. Ví dụ:
Trong đó /api/products là đường dẫn tài nguyên; category và page là tham số truy vấn dùng để lọc và phân trang.
Header
Header mang thông tin bổ sung về yêu cầu, chẳng hạn:
- Kiểu dữ liệu client muốn nhận.
- Kiểu dữ liệu gửi lên.
- Token xác thực.
- Ngôn ngữ hoặc thông tin cache.
Ví dụ, Content-Type: application/json cho biết phần body được biểu diễn bằng JSON.
Body
Body chứa dữ liệu mà client gửi lên. Khi tạo một sản phẩm, request có thể chứa:
Request GET thường không dùng body để truyền tiêu chí tìm kiếm; các tham số phù hợp thường được đặt trong URI.
HTTP response gồm những gì?
Sau khi xử lý, server trả về response gồm status code, header và có thể có body.
Status code
Status code là mã ba chữ số mô tả kết quả xử lý yêu cầu. Theo chuẩn HTTP, các mã được chia thành năm nhóm:
- 1xx: thông tin về quá trình xử lý.
- 2xx: yêu cầu đã được tiếp nhận và xử lý thành công.
- 3xx: cần chuyển hướng hoặc dùng tài nguyên ở vị trí khác.
- 4xx: yêu cầu từ client có vấn đề hoặc không được phép.
- 5xx: server gặp lỗi khi xử lý một yêu cầu hợp lệ.
Một số mã thường gặp:
- 200 OK: yêu cầu thành công.
- 201 Created: đã tạo tài nguyên mới.
- 204 No Content: xử lý thành công nhưng không cần trả body.
- 400 Bad Request: dữ liệu hoặc cú pháp yêu cầu không hợp lệ.
- 401 Unauthorized: chưa có thông tin xác thực hợp lệ.
- 403 Forbidden: đã nhận diện nhưng không có quyền thực hiện.
- 404 Not Found: không tìm thấy tài nguyên.
- 409 Conflict: yêu cầu xung đột với trạng thái hiện tại.
- 500 Internal Server Error: lỗi không mong muốn phía server.
Status code không thay thế hoàn toàn nội dung lỗi. Một API tốt thường trả thêm mã lỗi nội bộ, thông điệp dễ hiểu và chi tiết vừa đủ để client xử lý.
Response body
Body có thể chứa tài nguyên, danh sách tài nguyên hoặc thông tin lỗi. Ví dụ:
Không nên trả stack trace, câu truy vấn cơ sở dữ liệu hoặc thông tin hạ tầng nhạy cảm cho client.
Một yêu cầu API đi qua hệ thống như thế nào?
Giả sử người dùng mở trang chi tiết sản phẩm. Luồng xử lý có thể diễn ra như sau:
- Giao diện gửi GET /api/products/125.
- Server nhận request và định tuyến đến hàm xử lý phù hợp.
- Hệ thống kiểm tra tham số và quyền truy cập nếu cần.
- Lớp nghiệp vụ yêu cầu lớp dữ liệu tìm sản phẩm.
- Cơ sở dữ liệu thực hiện truy vấn.
- Server chuyển dữ liệu thành representation phù hợp.
- Response với status code và JSON được gửi về client.
- Giao diện cập nhật trạng thái tải, thành công hoặc lỗi.
Luồng trên cho thấy gọi API không chỉ là “lấy JSON”. Nó liên quan đến thiết kế tài nguyên, kiểm tra đầu vào, nghiệp vụ, truy cập dữ liệu và trải nghiệm lỗi trên giao diện.
Stateless trong REST có nghĩa là gì?
Stateless nghĩa là mỗi request phải mang đủ thông tin để server hiểu và xử lý nó. Server không nên phụ thuộc vào một chuỗi hội thoại bí mật được giữ giữa hai request để biết client muốn gì.
Điều này không có nghĩa hệ thống không được lưu dữ liệu. Server vẫn lưu tài khoản, đơn hàng, token hoặc session khi kiến trúc yêu cầu. Điểm cốt lõi là trạng thái của từng tương tác phải được biểu diễn rõ, giúp các request có thể được xử lý độc lập hơn.
Stateless hỗ trợ khả năng mở rộng vì nhiều server có thể tiếp nhận request. Tuy nhiên, hệ thống thực tế vẫn cần chiến lược xác thực, cache và đồng bộ dữ liệu phù hợp.
Idempotent là gì và vì sao cần biết?
Một phương thức được gọi là idempotent khi thực hiện cùng một yêu cầu hợp lệ nhiều lần có tác động dự kiến tương đương với thực hiện một lần.
Ví dụ, đặt trạng thái đơn hàng thành CANCELLED bằng PUT nhiều lần về nguyên tắc vẫn dẫn đến trạng thái cuối là CANCELLED. Ngược lại, gửi POST tạo đơn hàng nhiều lần có thể tạo ra nhiều đơn nếu hệ thống không có cơ chế chống trùng.
Hiểu idempotency giúp lập trình viên xử lý retry khi mạng chập chờn, đặc biệt ở thanh toán và các nghiệp vụ nhạy cảm. Đây là khái niệm thường bị bỏ qua khi người mới chỉ tập trung vào việc request có chạy hay không.
REST API khác WebSocket như thế nào?
REST API qua HTTP thường phù hợp với mô hình request–response: client hỏi và server trả lời. WebSocket tạo kết nối hai chiều kéo dài, phù hợp với chat, trạng thái trực tuyến hoặc dữ liệu cập nhật liên tục.
Hai cách này không loại trừ nhau. Một ứng dụng chat có thể dùng REST API để đăng nhập và tải lịch sử tin nhắn, đồng thời dùng WebSocket để nhận tin nhắn mới theo thời gian thực.
Những lỗi người mới thường gặp khi học API
- Chỉ sao chép đoạn gọi API mà không đọc method, URL, header và body.
- Cho rằng status code nào khác 200 cũng là lỗi server.
- Không thiết kế trạng thái đang tải, dữ liệu rỗng và lỗi mạng trên giao diện.
- Đưa khóa bí mật hoặc thông tin quản trị trực tiếp vào ứng dụng Mobile.
- Tin rằng dùng HTTPS tự động giải quyết mọi vấn đề bảo mật.
- Không kiểm tra dữ liệu ở server vì cho rằng client đã kiểm tra.
- Trả về cấu trúc JSON khác nhau tùy tiện giữa các endpoint.
Người mới nên thực hành REST API theo lộ trình nào?
Bước 1: Hiểu HTTP trước thư viện
Hãy nắm request, response, method, URI, header, body và status code. Khi đó, bạn sẽ hiểu thư viện đang giúp mình làm gì thay vì xem nó như một phép màu.
Bước 2: Dùng công cụ kiểm thử API
Thực hành gửi GET, POST, PUT, PATCH và DELETE đến một API mẫu. Quan sát kỹ request và response thay vì chỉ nhìn dữ liệu thành công.
Bước 3: Xây API CRUD nhỏ
Một API quản lý công việc hoặc sản phẩm là đủ để học:
- Thiết kế endpoint.
- Kiểm tra dữ liệu.
- Kết nối cơ sở dữ liệu.
- Xử lý lỗi.
- Phân trang và tìm kiếm.
Bước 4: Kết nối giao diện Web hoặc Mobile
Sau khi API hoạt động, hãy gọi nó từ ReactJS, Android, Flutter hoặc React Native. Giao diện cần thể hiện tối thiểu ba trạng thái: đang tải, có dữ liệu và gặp lỗi.
Bước 5: Bổ sung xác thực và quyền truy cập
Học cách phân biệt authentication và authorization, quản lý token, giới hạn dữ liệu được phép xem và không để lộ thông tin nhạy cảm trong response.
Học REST API trong các khóa lập trình tại CodeFresher
REST API không phải một môn học tách rời hoàn toàn. Kiến thức này nằm ở điểm giao nhau giữa Frontend, Backend và Mobile.
Nếu muốn tự xây dựng API, kết nối cơ sở dữ liệu và hiểu quy trình xử lý phía server, bạn có thể tham khảo khóa Java Web FullStack tại CodeFresher. Lộ trình đi từ nền tảng Java, Web đến Spring Boot, cơ sở dữ liệu và project thực tế.
Nếu mục tiêu là phát triển ứng dụng, các khóa Android Java–Kotlin, Flutter và React Native đều có nội dung làm việc với HTTP, JSON và API. Điểm quan trọng là người học không chỉ gọi được endpoint mà còn biết xử lý trạng thái tải, lỗi mạng và dữ liệu không hợp lệ trên giao diện.
Một lộ trình có bài tập và mentor hữu ích khi bạn thường xuyên mắc lỗi cấu hình, không đọc được response hoặc chưa biết chia vấn đề thành từng lớp. Tuy nhiên, khóa học không thay thế việc tự gõ code và quan sát request thực tế.
Kết luận
REST API là cách phổ biến để các ứng dụng Web, Mobile và hệ thống Backend trao đổi tài nguyên qua mạng. Để hiểu API, người mới cần nắm năm điểm: tài nguyên, endpoint, HTTP method, status code và representation.
Đừng dừng ở việc “gọi API ra dữ liệu”. Hãy theo dõi toàn bộ đường đi của request từ giao diện đến server, cơ sở dữ liệu và quay trở lại. Khi hiểu được luồng này, bạn sẽ học Frontend, Backend hoặc Mobile chắc hơn và sửa lỗi có phương pháp hơn.
Nội dung bài viết được chia sẻ bởi Thầy Duy – Thạc sĩ Công nghệ Thông tin tại Đại học Bách Khoa Hà Nội, người có nhiều năm kinh nghiệm trong giảng dạy và nghiên cứu lập trình. Bài viết giúp bạn hiểu rõ về Null Safety, vòng lặp when và cách khai báo class với nhiều constructor trong lập trình Android bằng Kotlin. Nếu bạn quan tâm đến kiến thức chuyên sâu về phát triển ứng dụng Android, đừng bỏ lỡ các kênh chia sẻ học liệu từ Thầy.
- Kênh YouTube: https://www.youtube.com/@LeHongDuyCNTT
- GitHub cá nhân: https://github.com/DuyLeHong
Địa chỉ: Trung tâm CodeFresher – Số 104 Hoàng Ngân, Cầu Giấy, Hà Nội.
SĐT: 0813188668 , 0332026803 (Zalo / Call)
