API thực sự là gì

Cách gọn gàng nhất để hình dung một API là một tấm thực đơn các yêu cầu mà một chương trình cung cấp cho chương trình khác.

Một nhà hàng không để bạn đi thẳng vào bếp và tự nấu. Họ đưa cho bạn một thực đơn: đây là những món bạn có thể gọi, đây là cách gọi món, đây là những gì bạn sẽ nhận được. Bạn không cần biết bếp hoạt động ra sao. Bạn chỉ cần thực đơn. Một API chính xác là như vậy — một công ty nói "đây là những yêu cầu bạn được phép gửi đến dịch vụ của chúng tôi, và đây là những gì mỗi yêu cầu trả về."

Khi AI viết code "gọi API thời tiết," nó đang gọi món từ thực đơn đó: cho tôi dự báo thời tiết của thành phố này. Máy chủ của công ty thời tiết làm việc và trả lại câu trả lời. Ứng dụng của bạn không bao giờ thấy cơ sở dữ liệu hay code của họ. Nó chỉ nhận món ăn.

   ┌────────────┐   request: GET /forecast?city=London   ┌────────────┐
   │  YOUR APP  │ ─────────────────────────────────────▶ │    API     │
   │  (client)  │                                         │  endpoint  │
   │            │ ◀───────────────────────────────────── │  (server)  │
   └────────────┘   response: { "temp": 14, ... } (JSON)  └────────────┘
      orders off                                          does the work,
      the menu                                            sends the dish

Sự thay đổi tư duy quan trọng: một API là một hợp đồng. Công ty kia hứa rằng nếu bạn hỏi theo một cách cụ thể, bạn sẽ nhận được câu trả lời theo một hình dạng cụ thể. Việc của bạn — và của AI — là hỏi đúng cách và đọc câu trả lời đúng cách. Hầu hết lỗi API là do một bên phá vỡ hợp đồng đó.