Ảnh của Phillip Blackowl
Trước lúc học dev, tui tưởng API là một loại bia.
Sau khi học dev, tui dùng API nhiều đến mức tui vừa đến quán bar và gọi món API.
Nhân viên quán bar báo lỗi 404: resource not found.
Tui đã gặp nhiều người - cả trong nghề tech và không trong nghề tech - có những khái niệm rất mơ hồ hoặc thậm chí không đúng về thuật ngữ này.
API viết tắt cho Application Programming Interface. Hầu hết các công ty lớn đều từng hoặc sẽ làm API để phục vụ khách, hoặc để nội bộ dùng.
Nhưng làm sao để miêu tả API mà không dùng ngôn ngữ kỹ thuật phức tạp? Ngoài công nghệ với doanh nghiệp ra thì API còn nghĩa gì khác không? Đầu tiên, chúng ta cùng nhau xem web hoạt động như thế nào nhé.

WWW và remote server

Khi nhắc tới Web, tui sẽ tưởng tượng ra một đống server kết nối với nhau.
Mỗi một trang trên Internet đều được lưu ở một cái remote server đâu đó ngoài kia. Remote server là một cái máy tính ở xa mình, được tối ưu hóa cho việc xử lý yêu cầu.
Bạn hoàn toàn có thể tự làm một cái server trong laptop của mình để trình làng nguyên cái website ra cho thế giới xem (server trong máy của mình gọi là local server, các kỹ sư thường dùng local server để phát triển website trước khi đem nó ra công chúng).
Khi bạn gõ www.facebook.com vào trình duyệt, bạn đang gửi một yêu cầu tới remote server của Facebook. Khi trình duyệt của bạn nhận được phản hồi, nó sẽ dịch đoạn code ra và hiển thị thành website cho bạn xem.
Đối với trình duyệt  - hay nên gọi là client trong trường hợp này - thì server của Facebook là một API. Như vậy, mỗi lần bạn truy cập trang web nào đó, bạn đang tương tác với API của một server.
API khác với remote server - nó chỉ là một bộ phận của remote server chuyên dùng để nhận yêu cầu và gửi phản hồi mà thôi.

Dùng API để phục vụ khách

Chắc bạn từng nghe tới chuyện công ty đóng gói API để phục vụ khách hàng. Ví dụ, Weather Underground bán quyền truy cập đến API chứa dữ liệu thời tiết của họ.
Tình huống: Công ty của bạn dùng một cái form để sắp xếp lịch hẹn với khách. Bạn muốn cho khách quyền tạo một sự kiện lên Google Calendar kèm các chi tiết cần thiết của cuộc hẹn.
Áp dụng API: Mình sẽ tìm cách cho server của công ty trò chuyện với server của Google, gửi cho Google yêu cầu tạo sự kiện trên Google Calendar kèm chi tiết cần thiết. Server của bạn sẽ nhận được phản hồi từ Google, xử lý nó, sau đó gửi lại các thông tin cần thiết đến trình duyệt - chẳng hạn như một mẩu thông báo xin người dùng xác nhận thông tin.
Hoặc, trình duyệt của bạn có thể gửi một API yêu cầu trực tiếp server của Google mà không cần thông qua server của bạn.
Server API của Google Calendar khác gì với các server ngoài kia?
Khác nhau ở format của yêu cầu và phản hồi.
Để render một trang web, trình duyệt của bạn cần một phản hồi dưới dạng HTML, nhưng API của Google Calendar sẽ chỉ cung cấp dữ liệu mà thôi - khả năng cao dưới dạng JSON.
Nếu server của công ty bạn là thứ gửi yêu cầu, thì server của công ty bạn là client (đứa nào gửi yêu cầu thì đứa đó là client, như hồi nãy trình duyệt  gửi yêu cầu thì trình duyệt là client).
Dưới góc độ khách hàng, người ta có thể hoàn thành lịch hẹn mà không cần phải rời trang web của công ty bạn.
Hầu hết các website hiện đại đều dùng API từ bên thứ ba.
Hầu hết các vấn đề đều đã có sẵn các giải pháp, dưới dạng thư viện (library) hoặc dịch vụ. Dùng các giải pháp có sẵn từ bên thứ ba hợp lý hơn tự tạo nhiều.
Các team dev cũng thường tách ứng dụng ra thành nhiều server khác nhau rồi cho các server này trò chuyện với nhau thông qua API. Các server thực hiện chức năng hỗ trợ cho server chính của ứng dụng thường được gọi là microservice.
Tóm lại, khi một công ty đưa API cho người dùng, công ty đang đưa cho người dùng một cụm URLs mà chỉ trả lại (return) các phản hồi thuần dữ liệu - tức là các phản hồi này sẽ không chứa phần trình bày như trong các môi trường có GUI (giao diện đồ họa người dùng) như trang web.
Bạn có thể gửi yêu cầu mà chỉ dùng trình duyệt  được không? Thường là được. Do dữ liệu HTTP được truyền dưới dạng text, trình duyệt  sẽ luôn cố gắng hiển thị yêu cầu ra cho bạn xem.
Ví dụ, bạn có thể truy cập trực tiếp đến API của GitHub mà không cần access token. Đây là phản hồi dưới dạng JSON bạn sẽ nhận được khi vào API route của một user GitHub bằng trình duyệt  (https://api.github.com/users/petrgazarov):
{
  "login": "petrgazarov",
  "id": 5581195,
  "avatar_url": "https://avatars.githubusercontent.com/u/5581195?v=3",
  "gravatar_id": "",
  "url": "https://api.github.com/users/petrgazarov",
  "html_url": "https://github.com/petrgazarov",
  "followers_url": "https://api.github.com/users/petrgazarov/followers",
  "following_url": "https://api.github.com/users/petrgazarov/following{/other_user}",
  "gists_url": "https://api.github.com/users/petrgazarov/gists{/gist_id}",
  "starred_url": "https://api.github.com/users/petrgazarov/starred{/owner}{/repo}",
  "subscriptions_url": "https://api.github.com/users/petrgazarov/subscriptions",
  "organizations_url": "https://api.github.com/users/petrgazarov/orgs",
  "repos_url": "https://api.github.com/users/petrgazarov/repos",
  "events_url": "https://api.github.com/users/petrgazarov/events{/privacy}",
  "received_events_url": "https://api.github.com/users/petrgazarov/received_events",
  "type": "User",
  "site_admin": false,
  "name": "Petr Gazarov",
  "company": "PolicyGenius",
  "blog": "http://petrgazarov.com/",
  "location": "NYC",
  "email": "[email protected]",
  "hireable": null,
  "bio": null,
  "public_repos": 23,
  "public_gists": 0,
  "followers": 7,
  "following": 14,
  "created_at": "2013-10-01T00:33:23Z",
  "updated_at": "2016-08-02T05:44:01Z"
}
Trình duyệt cũng hiển thị JSON khá tốt đấy chứ. Bạn có thể dễ dàng lấy data từ phần text phía trên và làm gì tùy thích.
A là “Application”
Để kết thúc bài viết hôm nay, tui sẽ chèn vào đây thêm vài ví dụ của API.
Application (còn gọi là app - ứng dụng) có thể chỉ nhiều thứ khác nhau. Nếu đang bàn về mặt API thì Application có thể chỉ hai thứ:
Một mẩu phần mềm với một chức năng nhất định. Toàn bộ server, toàn bộ app, hoặc chỉ một phần nhỏ của app.
Tức là bất cứ phần mềm nào có thể tách riêng hoàn toàn với môi trường của nó đều có thể tính là phần A trong API, và nhiều khi phần mềm đó có sẵn API của riêng nó rồi đấy.
Giả sử bạn dùng thư viện của bên thứ ba. Sau khi nhét vào code, thư viện đó sẽ trở thành một phần của app bạn. Là một phần mềm riêng biệt, thư viện đó hẳn có một cái API riêng để trò chuyện với phần code còn lại trong app của bạn.
Thêm cái ví dụ nữa: Trong Object Oriented Design (Thiết kế hướng đối tượng), code sẽ được gói gọn thành các object khác nhau. Ứng dụng của bạn có thể có hàng trăm object trò chuyện với nhau.
Mỗi một object đều có API cả đấy - API của nó chính là các public method và property (thuộc tính) dùng để tương tác với các object khác.
Object cũng có thể có những thành phần khác nhưng lại private - không thể được truy cập bởi những thành phần ngoài object - và vì vậy không thể được tính là API.
Tui hy vọng các bạn đã hiểu được nghĩa chung chung cũng như định nghĩa thường dùng ngày nay của API.
. . .
Một số tài liệu khác để tìm hiểu thêm:
.   .   .
Dịch bởi Students Who Code