Rất nhiều người có khái niệm khá mơ hồ và thiếu chính xác về thuật ngữ thông dụng này.
Về “máy móc”, API là viết tắt của Application Programming Interface (giao diện lập trình ứng dụng). Hầu như công ty nào cũng đã từng xây dựng qua API cho khách hàng, hoặc cho mục đích nội bộ.
Nhưng, ta phải giải thích “chi tiết” về API như thế nào? Và liệu khái niệm này có trộng hơn khái niệm người ta vẫn thường dùng trong lập trình và kinh doanh hay không? Trước hết, hãy lùi lại một chút, và xem thử bản thân môi trường web hoạt động như thế nào?
WWW and remote servers
Khi nói đến Web, tôi tưởng tượng ra một mạng lưới server khổng lồ kết nối với nhau.
Mỗi page trên internet được lưu trữ đâu đó trong một remote server. Remote server cũng không quá “huyền ảo”, mà chỉ là một máy tính được đặt tại một vị trí nhất định, được tối ưu để xử lý requests.
Nói cách khác, bạn có thể hoàn toàn biến chiếc laptop của mình thành một server có khả năng đưa website lên Web (trong thực tế, local server là phương tiện để các kỹ sư có thể phát triển website trước khi tung ra công khai).
Khi bạn gõ www.facebook.com trên trình duyệt, một request sẽ được gửi đến remote server của Facebook. Khi trình duyệt đã nhận được phản hồi, code sẽ được dịch và page được hiển thị.
Với trình duyệt (hay còn gọi là client), server của Facebook là một API. Đồng nghĩa với việc mỗi khi bạn truy cập một page trên Web, bạn sẽ tương tác với API của remote server tương ứng.
Lưu ý, API không phải là remote server – mà là một bộ phận của server, chịu trách nhiện nhận requests và gửi phản hồi.
APIs as a way to serve your customers
Bạn chắc hẳn cũng đã nghe nhiều công ty đóng gói APIs làm sản phẩm. Ví dụ, Weather Underground bán quyền truy cập đến weather data API của mình.
Trường hợp ví dụ: website của doanh nghiệp (nhỏ) của bạn đang dùng form đăng ký hẹn với khách hàng. Bạn muốn tạo điều kiện cho khách hàng tự động tạo sự kiện trên Google calendar, với chi tiết của cuộc hẹn.
Sử dụng API: Ta sẽ thiết đặt server của website giao tiếp trực tiếp với server của Google với một request tạo event theo chi tiết nhận được. Sau đó, server của bạn sẽ nhận được phản hồi từ Google, xử lý, và gửi các thông tin liên quan trở lại trình duyệt của người dùng (như message xác nhận chẳng hạn).
Hơn nữa, trình duyệt còn có thể trực tiếp gửi API request đến server của Google mà không cần thông qua server của bạn.
Như vậy, API này của Google Calendar có gì khác với API của các remote server khác?
Từ góc nhìn kỹ thuật, điểm khác biệt nằm ở chỗ format của request và của phản hồi.
Để render cả trang web, trình duyệt cần nhận phản hồi ở dạng HTML (thường chứa code hiển thị), trong khi API call của Google Calendar chỉ phản hồi data – thường ở định dạng JSON.
Nếu server của website của bạn thực hiện API request, thì server đó là client (tương tự như trình duyệt, đóng vai client khi được sử dụng để truy cập một webite).
Từ góc nhìn của người dùng, APIs cho phép họ hoàn thành thao tác mà không khải rời khỏi trang web của bạn.
Hiện nay, hầu như website nào cũng có sử dụng API của bên thứ ba.
Nhiều vấn đề hiện đã có giải pháp, dưới dạng thư viện hay dịch vụ, từ bên thứ ba. Những giải pháp sẵn có này thường là lời đáp “nhanh-gọn-nhẹ” ta có thể áp dụng ngay.
Đồng thời, ta cũng thường thấy, nhiều team hiện nay thường chhia ứng dụng sang nhiều server, giao tiếp với nhau thông qua APIs. Những server thực hiện chức năng hỗ trợ cho server ứng dụng chính thường được gọi là microservices.
Tóm lại, Khi một công ty bán API cho khách hàng, họ chỉ thực chất đang xây dựng một bộ URLs, phản hồi kết quả chỉ gồm data – nói cách khác, phản hồi sẽ không chứa kiểu thông tin hiển thị nặng nề mà bạn thường thấy trên một websites.
Bạn có thể thực hiện những request kiểu này bằng trinhd duyệt không? Thông thường, được, vì quá trình chuyển giao HTTP được thực hiện dưới dạng text, nên trình duyệt sẽ luôn tìm mọi cách để hiển thị phản hồi.
Ví dụ, bạn có thể truy cập API của GitHub trực tiếp với trình duyệt, mà không cần đến access token. Khi truy cập đường dẫn API của một người dùng GitHub (https://api.github.com/users/petrgazarov), đây là phản hồi JSON bạn nhận được:
{
"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": "petrgazarov@gmail.com",
"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"
}
Như vậy, trình duyệt hoàn toàn có thể hiện thị phản hồi JSON. Bạn đã có thể tách data từ những kết quả JSON như thế này (dạng text), và áp dụng ngay vào code của mình. Sau đó, bạn muốn làm gì với data thì làm.
A is for “Application”
“Application” có thể ám chỉ nhiều thứ. Trong phạm vi API, Application có thể là:
- Một phần mềm với chức năng riêng riêng biệt.
- Cả server, cả ứng dụng, hoặc một phần nhỏ của ứng dụng.
Về cơ bản, bất cứ phần mềm nào cũng có thể được tách biệt rạch ròi khỏi moi trường của nó, có thể trở thành “A” trong API, và có thể sẽ chứa một API nào đó.
Giả sử bạn đang dùng một thư viện (của bên thứ ba) trong code của mình. Khi đã được kết hợp vào code, thư viện này sẽ trở thành một phần của ứng dụng. Vì thư viện vẫn là một phần mềm riêng biệt, nên sẽ cần API để có thể tương tác với code.
Đây là một ví dụ nữa: Theo phong cách OOD (Object Oriented Design), code được sắp xếp thành objects. Ứng dụng của các bạn có thể có hàng trăm objects (được xác định) có thể tương tác với nhau.
Mỗi object có một API – một bộ method public (công khai) và các thuộc tính cần có, để tương tác với các objects khác trong ứng dụng.
Một inner logic private (riêng tư), bị ẩn đi trước các tác nhân bên ngoài (ngoại trừ API).
Hy vọng, thông qua bài viết, các bạn đã có thể hiển thêm về API, cũng như những khái niệm và chủ thể mà API chỉ đến trong nhiều trường hợp khác nhau.
Techtalk via freecodecamp
