Hãy tưởng tượng bạn mở một đơn hàng trong ứng dụng. Màn hình cần dữ liệu chưa có sẵn. API là cách đã thống nhất để một phần mềm hỏi phần mềm khác về thông tin hoặc yêu cầu thực hiện một việc. Hai bên có thể thay đổi độc lập miễn vẫn tuân theo thỏa thuận.
Yêu cầu có nơi đến và mục đích
Một yêu cầu web API thường xác định địa chỉ, phương thức và thông tin bổ sung mà dịch vụ cần. Địa chỉ chỉ tài nguyên. Phương thức thể hiện thao tác dự định. Header có thể mang ngữ cảnh như định dạng mong muốn hoặc thông tin xác thực.
Phần thân yêu cầu chứa dữ liệu gửi lên khi thao tác cần đến nó. Không phải yêu cầu nào cũng có phần thân và không phải API nào cũng dùng cùng quy ước.
GET /orders/42
Accept: application/json
Ví dụ phản hồi:
{ "id": 42, "status": "confirmed" }Máy chủ vẫn là bên quyết định
Nhìn thấy một nút không chứng minh người dùng có quyền thao tác. Máy chủ phải kiểm tra ai đang gửi yêu cầu và hành động đó có được phép không. Giá trị từ màn hình là đầu vào cần xác thực.
Điều này quan trọng khi tích hợp hệ thống. Màn hình có thể đang hiển thị trạng thái cũ trong khi nhân viên khác đã sửa đơn. Dịch vụ có thể từ chối thay đổi không còn phù hợp.
Cần hiểu đúng phản hồi
Lỗi mạng để lại câu hỏi quan trọng: dịch vụ đã nhận thao tác chưa? Gửi lại một lần đọc khác với gửi lại hành động có thể tạo thêm đơn. Thiết kế việc thử lại theo từng thao tác, không chỉ thêm một nút chung.
- Kiểm tra thao tác có thành công trước khi dùng dữ liệu trả về.
- Phân biệt không tìm thấy tài nguyên với không đủ quyền.
- Hiển thị trạng thái tải phù hợp khi chờ.
- Giải thích lỗi bằng ngôn ngữ người sử dụng hiểu được.
Đọc giao ước trước khi viết mã
Với API mới, tìm quy tắc xác thực, ví dụ yêu cầu, cấu trúc phản hồi, cách báo lỗi và phân trang. Kiểm tra cách xử lý gửi trùng và trường nào không bắt buộc.
Bắt đầu từ yêu cầu nhỏ nhất chạy thành công. Sau đó thử dữ liệu không hợp lệ và yêu cầu không đủ quyền. Hiểu ranh giới này hữu ích hơn kết nối mọi màn hình cùng lúc.
