[Giải thích đầy đủ] Cơ chế hoạt động của yêu cầu RESTful API - Học giao tiếp HTTP với Apidog

Giới thiệu

"API không trả về phản hồi..."

Bạn đã từng gặp tình huống này chưa? Tuần trước, tôi đã mất cả ngày để tìm ra nguyên nhân khi API đột nhiên ngừng hoạt động tại trang web của khách hàng. Mặc dù đã làm việc được một thời gian, tôi vẫn chưa thực sự hiểu rõ về "cơ chế hoạt động bên trong của API".

Thực tế, nhiều kỹ sư vẫn đang coi API như một "hộp đen". Cơ chế truyền dữ liệu chỉ với một cú nhấp chuột thực chất là tổng hợp của nhiều quy trình giao tiếp phức tạp hơn chúng ta tưởng.

Hôm nay, tôi sẽ sử dụng Apidog để giải thích chi tiết toàn bộ quy trình từ khi gửi yêu cầu API đến khi nhận được phản hồi! Trong bài viết này, tôi sẽ sử dụng Apidog làm công cụ client, Nginx làm reverse proxy, và Spring Boot + Tomcat cho backend. Ngoài ra, ở cuối bài viết, tôi đã chuẩn bị một demo API có thể thử ngay mà không cần đăng ký. Bạn có thể trải nghiệm toàn bộ quy trình API chỉ trong 3 phút!

Apidog là gì?

Trong bài viết này, tôi sử dụng Apidog làm client để gỡ lỗi API. Apidog là công cụ kiểm thử API trực quan, hỗ trợ xây dựng nhanh các yêu cầu, gỡ lỗi giao diện, kiểm tra dữ liệu phản hồi, rất phù hợp cho các nhà phát triển và kỹ sư kiểm thử. apidog

Bây giờ, hãy cùng sử dụng Apidog để khám phá quy trình hoạt động bên trong của các yêu cầu API!

1. Gửi yêu cầu từ Apidog!

Đầu tiên, mở Apidog, nhập URL yêu cầu và chọn phương thức (GET hoặc POST, v.v.). Sau khi thiết lập các tham số header và body nếu cần, nhấn nút send.

Tại thời điểm này, Apidog đóng gói thông tin bạn đã nhập thành một yêu cầu tuân thủ giao thức HTTP và chuẩn bị gửi qua mạng.

// Hình ảnh giao diện Apidog
URL: https://api.example.com/users
Method: GET
Headers: Authorization: Bearer token123
send ▶

apidog-request

Thực sự, chỉ với việc nhấn nút send này, rất nhiều quy trình phức tạp đang diễn ra phía sau. Hãy cùng xem những gì xảy ra "phía sau hậu trường"!

2. Hành trình của giao tiếp mạng

2-1. Phân giải DNS

Đầu tiên, giống như khi mở một trang web trong trình duyệt, tên miền trong URL (ví dụ: example.com) cần được chuyển đổi thành địa chỉ IP.

example.com → 93.184.216.34

Nếu không có bước này, chúng ta không thể biết phải kết nối với máy chủ nào trên internet. Máy chủ DNS đóng vai trò như một "danh bạ điện thoại".

2-2. Thiết lập kết nối TCP/IP

Tiếp theo, quá trình bắt tay ba bước TCP (SYN, SYN-ACK, ACK) diễn ra giữa client và server. Đây giống như một cuộc đối thoại: "Bạn có sẵn sàng để nói chuyện không?" "Vâng, tôi đã sẵn sàng!" "Tốt, hãy bắt đầu giao tiếp".

Đối với HTTPS, còn có thêm quá trình bắt tay mã hóa TLS/SSL. Đây là sự thỏa thuận để "có một cuộc trò chuyện bí mật".

2-3. Gửi yêu cầu HTTP

Sau khi thiết lập kết nối, dữ liệu yêu cầu được tạo trong Apidog sẽ được gửi đến máy chủ thông qua giao thức HTTP. Dữ liệu này có thể đi qua internet, mạng nội bộ, các nút CDN, v.v.

3. Reverse proxy và cân bằng tải

3-1. Reverse proxy

Trong nhiều môi trường sản xuất, một reverse proxy như Nginx sẽ nhận yêu cầu từ client và chuyển tiếp đến ứng dụng backend.

Client → Nginx → Ứng dụng backend

Điều này giúp tăng cường bảo mật và cung cấp các chức năng như bộ nhớ đệm.

3-2. Cân bằng tải

Trong các hệ thống lớn, thường có nhiều phiên bản backend. Trong trường hợp này, reverse proxy sẽ phân phối yêu cầu đến các máy chủ khác nhau dựa trên các thuật toán cụ thể (như round-robin hoặc least connections).

 ┌→ Máy chủ 1
Nginx ─┼→ Máy chủ 2 └→ Máy chủ 3

Điều này giúp cải thiện hiệu suất và tính khả dụng của toàn bộ hệ thống. Ban đầu, những cấu hình này có vẻ khó hiểu, nhưng khi thực hành, bạn sẽ hiểu sâu hơn!

4. Ứng dụng backend nhận yêu cầu

Hãy xem ví dụ với Java + Spring Boot:

Ứng dụng có Tomcat tích hợp đang lắng nghe trên một cổng (ví dụ: 8080). Khi yêu cầu đến, Spring sẽ ánh xạ nó đến phương thức Controller tương ứng dựa trên URL và phương thức HTTP:

@RestController
public class ExampleController { @PostMapping("/api/data") public ResponseEntity<DataResponse> getData(@RequestBody DataRequest request) { DataResponse response = dataService.process(request); return ResponseEntity.ok(response); }
}

Nhìn vào mã này, chúng ta có thể thấy rằng khi có yêu cầu POST đến /api/data, phương thức getData sẽ được gọi.

5. Xử lý logic nghiệp vụ

Controller thường gọi tầng Service để thực hiện logic nghiệp vụ. Ví dụ, truy vấn cơ sở dữ liệu, xác thực quy tắc, gọi các API khác:

@Service
public class DataService { public DataResponse process(DataRequest request) { // Xử lý logic nghiệp vụ return new DataResponse("OK"); }
}

Cá nhân tôi thấy việc thiết kế tầng này thú vị nhất. Logic nghiệp vụ chính là "bộ não" của ứng dụng!

6. Xây dựng dữ liệu phản hồi

Service trả về phản hồi cho Controller
Spring chuyển đổi đối tượng Java thành JSON và thiết lập header phản hồi Content-Type: application/json

Quá trình chuyển đổi này diễn ra tự động, vì vậy nhà phát triển không cần quan tâm đặc biệt. Thật tiện lợi phải không?

7. Trả về phản hồi cho Apidog

Backend đóng gói mã trạng thái HTTP, header phản hồi và nội dung phản hồi để gửi lại cho Apidog. Ví dụ:

{ "status": "success", "data": { "id": 1, "name": "example" }
}

Dữ liệu JSON này là thông tin cuối cùng mà chúng ta sẽ thấy.

8. Truyền dữ liệu qua mạng đến Apidog

Máy chủ gửi lại dữ liệu thông qua TCP/IP
Apidog nhận và phân tích phản hồi

9. Hiển thị phản hồi trong Apidog

Apidog cung cấp giao diện hiển thị đẹp mắt dựa trên mã trạng thái và nội dung phản hồi. Điều này giúp nhà phát triển nhanh chóng kiểm tra kết quả và gỡ lỗi.

Thực sự, tính năng hiển thị đẹp mắt này là một điểm mạnh của Apidog so với các client API khác. Đặc biệt, tính năng thu gọn JSON và phân biệt màu sắc rất dễ nhìn và hữu ích!

Demo thực tế: Trải nghiệm API trong 3 phút

Để tránh giới hạn tốc độ hoặc xác thực phức tạp, tôi sẽ sử dụng API thử nghiệm JSONPlaceholder. Rất tiện lợi vì có thể sử dụng ngay!

Mở Apidog
Tạo yêu cầu mới:
- Method: GET
- URL: https://jsonplaceholder.typicode.com/posts/1
Nhấp vào send
Bạn sẽ thấy phản hồi như sau (ví dụ):

{ "userId": 1, "id": 1, "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit", "body": "quia et suscipit..."
}

apidog-request

API này ổn định và không yêu cầu đăng nhập, nên rất lý tưởng cho việc demo yêu cầu HTTP. Ngay cả người mới bắt đầu cũng có thể thử nghiệm một cách an toàn!

Luồng hoạt động tổng thể của yêu cầu API

apidog

Kết luận

Từ khi nhấp vào nút send trong Apidog đến khi phản hồi được hiển thị, những quy trình phức tạp sau đây diễn ra:

Client xây dựng yêu cầu HTTP
Phân giải DNS và thiết lập kết nối TCP/IP
Reverse proxy và cân bằng tải
Ứng dụng backend nhận yêu cầu và thực hiện logic nghiệp vụ
Xây dựng và trả về phản hồi JSON
Client phân tích và hiển thị

Việc hiểu rõ các quy trình này giúp việc gỡ lỗi API hiệu quả hơn và nhanh chóng xác định vấn đề khi yêu cầu thất bại.

Cá nhân tôi thấy việc hiểu rõ "phần không nhìn thấy" này làm cho việc phát triển và kiểm thử API trở nên thú vị hơn. Đặc biệt, khi sử dụng công cụ trực quan như Apidog, bạn có thể nắm bắt giao tiếp HTTP phức tạp một cách trực quan, nên tôi khuyên người mới bắt đầu nên thử!

Hãy trải nghiệm quy trình hoạt động bên trong của yêu cầu API bằng Apidog. Nếu bạn có câu hỏi hoặc ý kiến, hãy để lại bình luận!