API Là Gì? Hiểu Rõ Trong 5 Phút Qua Những Ví Dụ Bạn Dùng Mỗi Ngày

Bạn mở một ứng dụng mua sắm mới, thấy nút “Đăng nhập bằng Google”, bấm vào, chọn tài khoản, và vài giây sau đã vào được ứng dụng mà không phải tạo mật khẩu nào. Ứng dụng đó không hề có mật khẩu Google của bạn. Vậy làm sao nó biết bạn là ai?

Câu trả lời nằm ở API. Nó cũng là thứ đứng sau ứng dụng thời tiết trên điện thoại, nút thanh toán trên website hay ô phí giao hàng tự tính ra ngay khi bạn nhập địa chỉ. Trong bài viết này, chúng ta sẽ tìm hiểu API là gì, một lần gọi API diễn ra thế nào, và bạn sẽ tự gọi thử một API thật ngay trên trình duyệt, không cần biết lập trình.

API là gì?

Cách dễ hình dung nhất là nghĩ tới người phục vụ trong nhà hàng. Bạn gọi món, người phục vụ chuyển yêu cầu vào bếp, rồi mang món ra khi bếp nấu xong. Bạn không cần vào bếp, cũng không cần biết bếp chia việc ra sao. Bạn chỉ cần gọi món theo đúng thực đơn.

API (Application Programming Interface, tạm dịch là giao diện lập trình ứng dụng) đóng đúng vai người phục vụ đó, nhưng giữa các phần mềm: nó là bộ quy tắc cho biết một phần mềm được yêu cầu những gì từ phần mềm khác, yêu cầu theo cách nào và sẽ nhận lại gì. Phần mềm gửi yêu cầu không cần biết bên kia được xây dựng bên trong ra sao, giống như bạn không cần biết công thức nấu món ăn.

Có một điểm hay bị nhầm: API không phải là ứng dụng. Ứng dụng thời tiết là thứ bạn mở ra dùng; API thời tiết là cách ứng dụng đó lấy dữ liệu dự báo từ một dịch vụ khác. Người dùng gần như không bao giờ nhìn thấy API, vì nó làm việc ở phía sau.

Một lần gọi API diễn ra thế nào?

Dù là API thời tiết hay API thanh toán, một lần gọi đều đi qua ba bước giống nhau: gửi yêu cầu, xử lý, trả kết quả. Mình sẽ dùng ví dụ ứng dụng thời tiết cho cả ba bước, để lát nữa bạn tự gọi thử thì thấy khớp.

1. Ứng dụng gửi request đến một endpoint

Request là yêu cầu mà ứng dụng gửi đi, nói rõ nó muốn gì. Ứng dụng thời tiết sẽ gửi đại ý: “cho tôi nhiệt độ và độ ẩm hiện tại ở Hà Nội”. Yêu cầu này được gửi tới một endpoint, tức một địa chỉ cụ thể mà API dành cho loại yêu cầu đó. Bạn có thể hình dung endpoint như từng quầy dịch vụ trong một tòa nhà: muốn lấy dự báo thời tiết thì đến đúng quầy thời tiết.

2. Máy chủ kiểm tra và xử lý

Máy chủ nhận request rồi kiểm tra trước khi làm: yêu cầu đã đủ thông tin chưa, có đúng định dạng không, bên gửi có được phép không. Nếu mọi thứ hợp lệ, nó mới đi tìm dữ liệu thời tiết. Nếu không, nó từ chối và báo lỗi, chẳng hạn thiếu tọa độ hay sai khóa truy cập, để ứng dụng biết vì sao không lấy được dữ liệu.

3. API trả về response

Response là phản hồi gửi lại cho ứng dụng: hoặc là dữ liệu cần lấy, hoặc là thông báo lỗi. Dữ liệu thường ở dạng JSON, một cách viết dữ liệu thành từng cặp “tên: giá trị” mà cả máy lẫn người đều đọc được. Ứng dụng đọc các giá trị đó rồi hiển thị thành con số nhiệt độ và biểu tượng thời tiết mà bạn thấy trên màn hình.

Ba bước này nghe vẫn hơi trừu tượng cho tới khi bạn tận mắt thấy một response thật. Phần tiếp theo làm đúng việc đó.

Thử gọi một API thật ngay trên trình duyệt

Open-Meteo là một dịch vụ dự báo thời tiết có API mở, không cần đăng ký hay API key khi dùng cho mục đích phi thương mại. Bạn chỉ cần mở đường dẫn dưới đây trên trình duyệt:

https://api.open-meteo.com/v1/forecast?latitude=21.0285&longitude=105.8542&current=temperature_2m,relative_humidity_2m&timezone=auto

Đường dẫn này chính là một request, và bạn có thể đọc nó theo từng phần:

• https://api.open-meteo.com/v1/forecast: endpoint, tức “quầy” dự báo thời tiết.
• latitude=21.0285&longitude=105.8542: vĩ độ và kinh độ của Hà Nội. Đổi hai số này là lấy được thời tiết nơi khác.
• current=temperature_2m,relative_humidity_2m: chỉ xin hai thứ là nhiệt độ và độ ẩm hiện tại.
• timezone=auto: trả giờ theo múi giờ của địa điểm, thay vì giờ GMT.

Trình duyệt sẽ hiện ra một khối JSON khá dài. Mình gọi thử lúc 22:45 ngày 13/11/2026 và nhận được kết quả như dưới đây (đã lược bớt vài trường kỹ thuật cho dễ nhìn):

{
  "timezone": "Asia/Bangkok",
  "current_units": {
    "temperature_2m": "°C",
    "relative_humidity_2m": "%"
  },
  "current": {
    "time": "2026-11-13T22:45",
    "temperature_2m": 18.8,
    "relative_humidity_2m": 91
  }
}

Phần bạn cần nhìn là khối current: lúc 22:45, Hà Nội có nhiệt độ 18,8 và độ ẩm 91. Còn khối current_units cho biết đơn vị, tức °C và %. Một ứng dụng thời tiết làm đúng những gì bạn vừa làm, chỉ khác là nó đọc các con số này bằng code rồi hiển thị đẹp hơn. Con số bạn nhận được khi mở link sẽ khác, vì đó là dữ liệu lúc bạn gọi.

API giúp các ứng dụng làm được gì?

Điều API mang lại là ứng dụng không phải tự xây mọi thứ. Một website bán hàng nhỏ không cần tự làm hệ thống xử lý thẻ: nó gửi yêu cầu thanh toán đến API của cổng thanh toán và nhận lại kết quả giao dịch. Nó cũng không cần tự lập bảng giá giao hàng cho từng tỉnh: khi khách nhập địa chỉ, website gửi địa chỉ và cân nặng đơn hàng đến API của đơn vị vận chuyển, rồi nhận lại phí giao để hiển thị. Quay lại ví dụ đầu bài: khi bạn bấm “Đăng nhập bằng Google”, ứng dụng chuyển bạn sang trang của Google để xác nhận, rồi nhận lại thông tin cho biết bạn là ai, còn mật khẩu thì chỉ Google giữ.

Các công cụ AI cũng đi theo cách này. Claude có giao diện chat cho người dùng, nhưng cũng có API để lập trình viên đưa khả năng của nó vào sản phẩm của mình.

Với người không lập trình, hiểu API giúp bạn hiểu đúng những câu rất hay gặp. Khi một phần mềm quảng cáo “tích hợp với Google Sheets”, nghĩa là nó gọi API của Google Sheets để đọc và ghi dữ liệu. Khi một công cụ báo “đã vượt giới hạn request”, bạn sẽ biết đó là giới hạn của API chứ không phải máy bạn bị lỗi.

API key và giới hạn request

Open-Meteo cho bạn gọi thoải mái, nhưng nhiều API khác yêu cầu một API key. Đó là một chuỗi ký tự mà nhà cung cấp cấp cho bạn khi đăng ký, gửi kèm mỗi request để họ biết yêu cầu đến từ ứng dụng hay dự án nào. Nhờ key, họ đếm được bạn đã dùng bao nhiêu, giới hạn và tính phí theo mức đó.

Cần hiểu đúng một điều: API key chủ yếu nhận diện ứng dụng, không phải chứng minh bạn là ai. Khi API cần biết người dùng cụ thể nào đang truy cập dữ liệu riêng của họ, như ví dụ đăng nhập bằng Google ở trên, nhà cung cấp dùng một cơ chế xác thực khác.

Cũng vì key gắn với việc đếm và tính phí, gần như API nào cũng có rate limit, tức giới hạn số request trong một khoảng thời gian. Gửi quá nhanh, bạn sẽ nhận mã lỗi 429 Too Many Requests, đôi khi kèm thông tin cho biết cần chờ bao lâu trước khi gửi tiếp.

REST, GraphQL và WebSocket: ba cái tên bạn sẽ gặp

Khi đọc tài liệu API, bạn sẽ gặp ba cái tên này. Mỗi cái là một cách khác nhau để thiết kế việc trao đổi giữa ứng dụng và máy chủ. Ở mức người mới, chỉ cần biết mỗi loại hợp với tình huống nào:

• REST: mỗi loại dữ liệu có một endpoint riêng, gửi request là nhận response, giống hệt ví dụ Open-Meteo ở trên. Đây là kiểu bạn sẽ gặp nhiều nhất.
• GraphQL: ứng dụng ghi rõ mình cần đúng những trường nào và nhận về chỉ những trường đó. Ví dụ màn hình hồ sơ chỉ cần tên và ảnh đại diện thì không phải tải thêm địa chỉ hay lịch sử mua hàng.
• WebSocket: giữ một kết nối mở giữa hai bên, để máy chủ chủ động đẩy dữ liệu mới về mà không cần ứng dụng hỏi lại. Hợp với ứng dụng chat, bảng giá cập nhật liên tục hay game trực tuyến.

Nếu mới bắt đầu, hãy học REST trước. Phần lớn API công khai theo kiểu này, và nắm được request, endpoint, response như bạn vừa làm là đã hiểu phần cốt lõi của nó.

Những hiểu lầm thường gặp về API

Bước tiếp theo: tự đổi request và xem kết quả

Cách nhanh nhất để API hết trừu tượng là tự sửa request. Mở lại đường dẫn Open-Meteo ở trên, đổi latitude và longitude sang tọa độ thành phố của bạn, hoặc thêm ,wind_speed_10m vào sau relative_humidity_2m để xin thêm tốc độ gió. Mỗi lần đổi, bạn đang làm đúng việc của một lập trình viên khi đọc tài liệu API: xem API nhận tham số gì và trả lại dữ liệu gì.

Câu hỏi thường gặp về API

Nguồn tham khảo

Các tài liệu dưới đây được kiểm tra ngày 13/11/2026:

• Open-Meteo — Weather Forecast API: tham số latitude, longitude, current, timezone và điều kiện dùng API key.
• Google Cloud — API Keys: mục đích, giới hạn và cách bảo vệ API key.
• MDN — 429 Too Many Requests: ý nghĩa mã lỗi và header Retry-After.
• GraphQL — Learn: cách GraphQL cho phép lấy đúng các trường cần dùng.
• MDN — WebSocket API: kết nối hai chiều và việc máy chủ chủ động gửi dữ liệu.