API là gì? Làm ơn bằng tiếng Anh.

Trước khi tôi học phát triển phần mềm, API nghe giống như một loại bia.

Hôm nay tôi sử dụng thuật ngữ này thường xuyên đến mức gần đây tôi đã cố gắng đặt một API tại một quán bar.

Phản ứng của người pha chế là ném 404: tài nguyên không tìm thấy.

Tôi gặp rất nhiều người, cả làm việc trong lĩnh vực công nghệ và những nơi khác, những người có ý tưởng khá mơ hồ hoặc không chính xác về ý nghĩa của thuật ngữ khá phổ biến này.

Về mặt kỹ thuật, API là viết tắt của Application Programming Interface . Tại một số thời điểm, hầu hết các công ty lớn đã xây dựng API cho khách hàng của họ hoặc để sử dụng nội bộ.

Nhưng làm thế nào để bạn giải thích API bằng tiếng Anh đơn giản? Và có nghĩa rộng hơn nghĩa được dùng trong phát triển và kinh doanh không? Đầu tiên, hãy quay lại và xem xét cách thức hoạt động của chính web.

WWW và máy chủ từ xa

Khi tôi nghĩ về Web, tôi tưởng tượng ra một mạng lưới lớn các máy chủ được kết nối .

Mọi trang trên internet đều được lưu trữ ở đâu đó trên máy chủ từ xa. Rốt cuộc, một máy chủ từ xa không quá thần bí - nó chỉ là một phần của một máy tính được định vị từ xa được tối ưu hóa để xử lý các yêu cầu.

Để mọi thứ theo quan điểm, bạn có thể tạo ra một máy chủ trên máy tính xách tay của mình có khả năng cung cấp toàn bộ trang web lên Web (trên thực tế, máy chủ cục bộ là thứ mà các kỹ sư sử dụng để phát triển trang web trước khi phát hành chúng ra công chúng).

Khi bạn nhập www.facebook.com vào trình duyệt của mình, một yêu cầu sẽ được gửi đến máy chủ từ xa của Facebook. Khi trình duyệt của bạn nhận được phản hồi, trình duyệt sẽ diễn giải mã và hiển thị trang.

Đối với trình duyệt, còn được gọi là máy khách , máy chủ của Facebook là một API. Điều này có nghĩa là mỗi khi bạn truy cập một trang trên Web, bạn sẽ tương tác với một số API của máy chủ từ xa.

API không giống như máy chủ từ xa - đúng hơn nó là một phần của máy chủ nhận yêu cầu và gửi phản hồi .

API như một cách để phục vụ khách hàng của bạn

Bạn có thể đã nghe nói về các công ty đóng gói API dưới dạng sản phẩm. Ví dụ: Weather Underground bán quyền truy cập vào API dữ liệu thời tiết của nó.

Tình huống ví dụ: Trang web của doanh nghiệp nhỏ của bạn có một biểu mẫu được sử dụng để đăng ký cuộc hẹn cho khách hàng. Bạn muốn cung cấp cho khách hàng của mình khả năng tự động tạo sự kiện lịch Google với các chi tiết cho cuộc hẹn đó.

Sử dụng API: Ý tưởng là để máy chủ của trang web của bạn nói chuyện trực tiếp với máy chủ của Google với yêu cầu tạo sự kiện với các chi tiết đã cho. Sau đó, máy chủ của bạn sẽ nhận phản hồi của Google, xử lý và gửi lại thông tin liên quan đến trình duyệt, chẳng hạn như thông báo xác nhận cho người dùng.

Ngoài ra, trình duyệt của bạn thường có thể gửi yêu cầu API trực tiếp đến máy chủ của Google bằng cách bỏ qua máy chủ của bạn.

API của Lịch Google này khác với API của bất kỳ máy chủ từ xa nào khác ngoài đó?

Về mặt kỹ thuật , sự khác biệt là định dạng của yêu cầu và phản hồi.

Để hiển thị toàn bộ trang web, trình duyệt của bạn mong đợi một phản hồi bằng HTML, chứa mã trình bày, trong khi lệnh gọi API của Lịch Google sẽ chỉ trả về dữ liệu - có thể ở định dạng như JSON .

Nếu máy chủ của trang web của bạn đang thực hiện yêu cầu API, thì máy chủ của trang web của bạn là máy khách (tương tự như trình duyệt của bạn là máy khách khi bạn sử dụng nó để điều hướng đến một trang web).

Từ góc độ người dùng của bạn, API cho phép họ hoàn thành hành động mà không cần rời khỏi trang web của bạn.

Hầu hết các trang web hiện đại sử dụng ít nhất một số API của bên thứ ba.

Nhiều vấn đề đã có giải pháp của bên thứ ba, có thể là ở dạng thư viện hoặc dịch vụ. Việc sử dụng giải pháp hiện có thường dễ dàng và đáng tin cậy hơn.

Không có gì lạ khi các nhóm phát triển chia nhỏ ứng dụng của họ thành nhiều máy chủ nói chuyện với nhau thông qua API. Các máy chủ thực hiện các chức năng trợ giúp cho máy chủ ứng dụng chính thường được gọi là microservices .

Tóm lại, khi một công ty cung cấp API cho khách hàng của họ, điều đó có nghĩa là họ đã xây dựng một tập hợp các URL chuyên dụng trả về các phản hồi dữ liệu thuần túy - có nghĩa là các phản hồi sẽ không chứa loại chi phí trình bày mà bạn mong đợi trong một giao diện người dùng đồ họa giống như một trang web .

Bạn có thể thực hiện những yêu cầu này với trình duyệt của mình không? Thường thì có. Vì quá trình truyền HTTP thực tế xảy ra dưới dạng văn bản, nên trình duyệt của bạn sẽ luôn làm tốt nhất có thể để hiển thị phản hồi.

Ví dụ: bạn có thể truy cập trực tiếp API của GitHub bằng trình duyệt của mình mà không cần mã thông báo truy cập. Đây là phản hồi JSON mà bạn nhận được khi truy cập vào tuyến API của người dùng GitHub trong trình duyệt của bạn (//api.github.com/users/petrgazarov):

{ "login": "petrgazarov", "id": 5581195, "avatar_url": "//avatars.githubusercontent.com/u/5581195?v=3", "gravatar_id": "", "url": "//api.github.com/users/petrgazarov", "html_url": "//github.com/petrgazarov", "followers_url": "//api.github.com/users/petrgazarov/followers", "following_url": "//api.github.com/users/petrgazarov/following{/other_user}", "gists_url": "//api.github.com/users/petrgazarov/gists{/gist_id}", "starred_url": "//api.github.com/users/petrgazarov/starred{/owner}{/repo}", "subscriptions_url": "//api.github.com/users/petrgazarov/subscriptions", "organizations_url": "//api.github.com/users/petrgazarov/orgs", "repos_url": "//api.github.com/users/petrgazarov/repos", "events_url": "//api.github.com/users/petrgazarov/events{/privacy}", "received_events_url": "//api.github.com/users/petrgazarov/received_events", "type": "User", "site_admin": false, "name": "Petr Gazarov", "company": "PolicyGenius", "blog": "//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 dường như đã hoạt động tốt khi hiển thị phản hồi JSON. Một phản hồi JSON như thế này đã sẵn sàng để sử dụng trong mã của bạn. Thật dễ dàng để trích xuất dữ liệu từ văn bản này. Sau đó, bạn có thể làm bất cứ điều gì bạn muốn với dữ liệu.

A là "Ứng dụng"

Để kết thúc, chúng ta hãy đưa ra thêm một vài ví dụ về API.

"Ứng dụng" có thể đề cập đến nhiều thứ. Dưới đây là một số trong số chúng trong ngữ cảnh của API:

  1. Một phần mềm với một chức năng riêng biệt.
  2. Toàn bộ máy chủ, toàn bộ ứng dụng hoặc chỉ một phần nhỏ của ứng dụng.

Về cơ bản, bất kỳ phần mềm nào có thể tách biệt rõ ràng với môi trường của nó, đều có thể là “A” trong API và có thể cũng sẽ có một số loại API.

Giả sử bạn đang sử dụng thư viện của bên thứ ba trong mã của mình. Sau khi được tích hợp vào mã của bạn, thư viện sẽ trở thành một phần của ứng dụng tổng thể của bạn. Là một phần mềm riêng biệt, thư viện có thể sẽ có một API cho phép nó tương tác với phần còn lại của mã của bạn.

Đây là một ví dụ khác: Trong Thiết kế hướng đối tượng , mã được tổ chức thành các đối tượng. Ứng dụng của bạn có thể có hàng trăm đối tượng được xác định có thể tương tác với nhau.

Mỗi đối tượng có một API - một tập hợp các phương thức và thuộc tính công khai mà nó sử dụng để tương tác với các đối tượng khác trong ứng dụng của bạn.

Một đối tượng cũng có thể có logic bên trong là riêng tư, có nghĩa là nóẩntừ phạm vi bên ngoài (và không phải là API).

Từ những gì chúng tôi đã đề cập, tôi hy vọng bạn hiểu được ý nghĩa rộng hơn của API cũng như những cách sử dụng phổ biến hơn của thuật ngữ ngày nay.

Tài nguyên thú vị (những thứ mà tôi đã bỏ qua nhưng vẫn rất tuyệt):

Một video youtube tuyệt vời trên DNS (Hệ thống tên miền)

Thông tin cơ bản về giao thức HTTP

Một video tuyệt vời của Học viện Khan về Nguyên tắc thiết kế hướng đối tượng