API là gì? Các thông tin tổng quan về API

API cho phép sản phẩm hoặc dịch vụ của bạn giao tiếp với các sản phẩm và dịch vụ khác mà không cần biết chúng được triển khai như thế nào. Điều này có thể đơn giản hóa việc phát triển ứng dụng, tiết kiệm thời gian và tiền bạc. Khi bạn đang thiết kế các công cụ và sản phẩm mới—hoặc quản lý các công cụ và sản phẩm hiện có—API mang đến cho bạn sự linh hoạt; đơn giản hóa thiết kế , quản trị và sử dụng; và cung cấp các cơ hội cho sự đổi mới.

API đôi khi được coi là hợp đồng, với tài liệu thể hiện thỏa thuận giữa các bên: Nếu bên 1 gửi yêu cầu từ xa được cấu trúc theo một cách cụ thể, thì đây là cách phần mềm của bên 2 sẽ phản hồi.

Do các API đơn giản hóa cách các nhà phát triển tích hợp các thành phần ứng dụng mới vào một kiến ​​trúc hiện có nên chúng giúp các nhóm CNTT và doanh nghiệp cộng tác với nhau. Nhu cầu kinh doanh thường thay đổi nhanh chóng để đáp ứng với thị trường kỹ thuật số luôn thay đổi, nơi các đối thủ cạnh tranh mới có thể thay đổi toàn bộ ngành bằng một ứng dụng mới. Để duy trì tính cạnh tranh, điều quan trọng là phải hỗ trợ sự phát triển và triển khai nhanh chóng các dịch vụ sáng tạo. Phát triển ứng dụng gốc trên đám mây là một cách có thể xác định được để tăng tốc độ phát triển và nó dựa vào việc kết nối kiến ​​trúc ứng dụng vi dịch vụ thông qua API.

API là một cách đơn giản hóa để kết nối cơ sở hạ tầng của riêng bạn thông qua phát triển ứng dụng gốc trên đám mây, nhưng chúng cũng cho phép bạn chia sẻ dữ liệu của mình với khách hàng và những người dùng bên ngoài khác. API công khai đại diện cho giá trị kinh doanh duy nhất vì chúng có thể đơn giản hóa và mở rộng cách bạn kết nối với đối tác của mình, cũng như có khả năng kiếm tiền từ dữ liệu của bạn (API Google Maps là một ví dụ phổ biến).

Ví dụ, hãy tưởng tượng một công ty phân phối sách. Nhà phân phối sách có thể cung cấp cho khách hàng của mình một ứng dụng đám mây cho phép nhân viên hiệu sách kiểm tra tình trạng sách còn hàng với nhà phân phối. Ứng dụng này có thể tốn kém để phát triển, bị giới hạn bởi nền tảng và yêu cầu thời gian phát triển lâu dài cũng như bảo trì liên tục.

Ngoài ra, nhà phân phối sách có thể cung cấp API để kiểm tra tình trạng còn hàng. Có một số lợi ích cho phương pháp này:

• Cho phép khách hàng truy cập dữ liệu qua API giúp họ tổng hợp thông tin về khoảng không quảng cáo của họ ở một nơi duy nhất.

• Nhà phân phối sách có thể thực hiện các thay đổi đối với hệ thống nội bộ của mình mà không ảnh hưởng đến khách hàng, miễn là hành vi của API không thay đổi.

• Với API có sẵn công khai, các nhà phát triển làm việc cho nhà phân phối sách, người bán sách hoặc bên thứ ba có thể phát triển ứng dụng để giúp khách hàng tìm thấy những cuốn sách họ đang tìm kiếm. Điều này có thể dẫn đến doanh thu cao hơn hoặc các cơ hội kinh doanh khác.

Nói tóm lại, API cho phép bạn mở quyền truy cập vào tài nguyên của mình trong khi vẫn duy trì bảo mật và kiểm soát. Bạn mở quyền truy cập như thế nào và cho ai là tùy thuộc vào bạn. Bảo mật API là tất cả về quản lý API tốt, bao gồm việc sử dụng cổng API . Việc kết nối với API và tạo ứng dụng sử dụng dữ liệu hoặc chức năng do API hiển thị có thể được thực hiện với nền tảng tích hợp phân tán kết nối mọi thứ—bao gồm các hệ thống cũ và Internet vạn vật (IoT) .

Việc hiển thị API của bạn cho đối tác hoặc công chúng có thể:

• Tạo các kênh doanh thu mới hoặc mở rộng các kênh hiện có.

• Mở rộng phạm vi tiếp cận của thương hiệu của bạn.

• Tạo điều kiện thuận lợi cho đổi mới mở hoặc nâng cao hiệu quả thông qua hợp tác và phát triển bên ngoài.

Âm thanh tuyệt vời, phải không? Nhưng làm thế nào các API có thể làm được tất cả những điều đó?

Hãy trở lại ví dụ về công ty phân phối sách.

Giả sử một trong những đối tác của công ty phát triển một ứng dụng giúp mọi người tìm sách trên giá sách. Trải nghiệm được cải thiện này mang lại nhiều người mua sắm hơn cho hiệu sách—khách hàng của nhà phân phối—và mở rộng kênh doanh thu hiện có.

Có thể bên thứ ba sử dụng API công khai để phát triển ứng dụng cho phép mọi người mua sách trực tiếp từ nhà phân phối thay vì từ cửa hàng. Điều này mở ra một kênh doanh thu mới cho nhà phân phối sách.

Chia sẻ API―với các đối tác được chọn hoặc toàn thế giới―có thể có tác động tích cực. Mỗi quan hệ đối tác mở rộng sự công nhận thương hiệu của bạn ngoài những nỗ lực tiếp thị của công ty bạn. Mở công nghệ cho mọi người, như với API công khai, khuyến khích các nhà phát triển xây dựng hệ sinh thái ứng dụng xung quanh API của bạn. Nhiều người sử dụng công nghệ của bạn hơn có nghĩa là nhiều người có khả năng hợp tác kinh doanh với bạn hơn.

Công khai công nghệ có thể dẫn đến những kết quả mới lạ và bất ngờ. Những kết quả này đôi khi phá vỡ toàn bộ ngành công nghiệp. Đối với công ty phân phối sách của chúng tôi, các công ty mới – chẳng hạn như dịch vụ mượn sách – có thể thay đổi cơ bản cách họ kinh doanh. Đối tác và API công khai giúp bạn sử dụng những nỗ lực sáng tạo của một cộng đồng lớn hơn nhóm các nhà phát triển nội bộ của bạn. Những ý tưởng mới có thể đến từ bất cứ đâu và các công ty cần nhận thức được những thay đổi trên thị trường của họ và sẵn sàng hành động theo những thay đổi đó. API có thể giúp ích.

API xuất hiện trong những ngày đầu tiên của máy tính, trước cả máy tính cá nhân. Vào thời điểm đó, API thường được sử dụng làm thư viện cho các hệ điều hành. API hầu như luôn là cục bộ của các hệ thống mà nó hoạt động, mặc dù đôi khi nó chuyển các thông báo giữa các máy tính lớn. Sau gần 30 năm, các API đã thoát ra khỏi môi trường cục bộ của chúng. Vào đầu những năm 2000, chúng đã trở thành một công nghệ quan trọng để tích hợp dữ liệu từ xa.

API từ xa được thiết kế để tương tác thông qua mạng truyền thông. Theo từ xa , chúng tôi muốn nói rằng các tài nguyên đang được API thao tác ở đâu đó bên ngoài máy tính thực hiện yêu cầu. Bởi vì mạng truyền thông được sử dụng rộng rãi nhất là internet, hầu hết các API được thiết kế dựa trên các tiêu chuẩn web. Không phải tất cả API từ xa đều là API web, nhưng thật công bằng khi cho rằng API web là từ xa.

API web thường sử dụng HTTP cho thông báo yêu cầu và cung cấp định nghĩa về cấu trúc của thông báo phản hồi. Các thông báo phản hồi này thường có dạng tệp XML hoặc JSON. Cả XML và JSON đều là các định dạng được ưu tiên vì chúng trình bày dữ liệu theo cách mà các ứng dụng khác dễ dàng thao tác.

Khi các API web đã lan rộng, một đặc tả giao thức đã được phát triển để giúp chuẩn hóa việc trao đổi thông tin: Giao thức truy cập đối tượng đơn giản, thường được gọi là SOAP. API được thiết kế bằng SOAP sử dụng XML cho định dạng thông báo của chúng và nhận yêu cầu thông qua HTTP hoặc SMTP. SOAP giúp các ứng dụng chạy trong các môi trường khác nhau hoặc được viết bằng các ngôn ngữ khác nhau chia sẻ thông tin dễ dàng hơn.

Một thông số kỹ thuật khác là Chuyển trạng thái đại diện (REST) ​​. API Web tuân thủ các ràng buộc kiến ​​trúc REST được gọi là API RESTful. REST khác với SOAP ở điểm cơ bản: SOAP là một giao thức, trong khi REST là một kiểu kiến ​​trúc. Điều này có nghĩa là không có tiêu chuẩn chính thức nào cho API web RESTful. Như được định nghĩa trong luận án của Roy Fielding “Phong cách kiến ​​trúc và thiết kế kiến ​​trúc phần mềm dựa trên mạng,” API là RESTful miễn là chúng tuân thủ 6 ràng buộc hướng dẫn của hệ thống RESTful:

• Kiến trúc máy khách-máy chủ : Kiến trúc REST bao gồm máy khách, máy chủ và tài nguyên và nó xử lý các yêu cầu thông qua HTTP.

• Không trạng thái : Không có nội dung máy khách nào được lưu trữ trên máy chủ giữa các yêu cầu. Thay vào đó, thông tin về trạng thái phiên được giữ với máy khách.

• Khả năng lưu vào bộ nhớ cache : Bộ nhớ đệm có thể loại bỏ nhu cầu đối với một số tương tác máy khách-máy chủ.

• Hệ thống phân lớp : Các tương tác máy khách-máy chủ có thể được trung gian bởi các lớp bổ sung. Các lớp này có thể cung cấp các tính năng bổ sung như cân bằng tải, bộ đệm dùng chung hoặc bảo mật.

• Mã theo yêu cầu (tùy chọn) : Máy chủ có thể mở rộng chức năng của máy khách bằng cách chuyển mã thực thi.

• Giao diện thống nhất : Ràng buộc này là cốt lõi đối với thiết kế API RESTful và bao gồm 4 khía cạnh:

  • Nhận dạng tài nguyên trong các yêu cầu : Tài nguyên được xác định trong các yêu cầu và tách biệt với các biểu diễn được trả lại cho khách hàng.

  • Thao tác tài nguyên thông qua các biểu diễn : Máy khách nhận các tệp biểu thị tài nguyên. Các đại diện này phải có đủ thông tin để cho phép sửa đổi hoặc xóa.

  • Thông báo tự mô tả : Mỗi thông báo được trả lại cho khách hàng chứa đủ thông tin để mô tả cách khách hàng nên xử lý thông tin.

  • Hypermedia là công cụ của trạng thái ứng dụng : Sau khi truy cập tài nguyên, ứng dụng khách REST sẽ có thể khám phá thông qua các siêu liên kết tất cả các hành động khác hiện có.

Những ràng buộc này có vẻ nhiều nhưng chúng đơn giản hơn nhiều so với một giao thức quy định. Vì lý do này, API RESTful đang trở nên phổ biến hơn SOAP.

Trong những năm gần đây, đặc tả OpenAPI đã nổi lên như một tiêu chuẩn chung để xác định API REST. OpenAPI thiết lập một cách thức không phụ thuộc vào ngôn ngữ để các nhà phát triển xây dựng các giao diện API REST sao cho người dùng có thể hiểu chúng mà không cần phỏng đoán nhiều.

Một tiêu chuẩn API khác sẽ xuất hiện là GraphQL , ngôn ngữ truy vấn và thời gian chạy phía máy chủ thay thế cho REST. GraphQL ưu tiên cung cấp cho khách hàng chính xác dữ liệu họ yêu cầu và không hơn thế nữa. Thay thế cho REST, GraphQL cho phép các nhà phát triển xây dựng các yêu cầu lấy dữ liệu từ nhiều nguồn dữ liệu trong một lệnh gọi API.

2 cách tiếp cận kiến ​​trúc sử dụng API từ xa nhiều nhất là kiến ​​trúc hướng dịch vụ (SOA) và kiến ​​trúc vi dịch vụ. SOA, cách tiếp cận lâu đời nhất trong số 2 cách tiếp cận, bắt đầu như một cải tiến cho các ứng dụng nguyên khối. Trong khi một ứng dụng nguyên khối duy nhất làm mọi thứ, một số chức năng có thể được cung cấp bởi các ứng dụng khác nhau được kết hợp lỏng lẻo thông qua một mẫu tích hợp, chẳng hạn như bus dịch vụ doanh nghiệp (ESB).

Mặc dù SOA, ở hầu hết các khía cạnh, đơn giản hơn kiến ​​trúc nguyên khối, nhưng nó có nguy cơ thay đổi theo tầng trong toàn bộ môi trường nếu các tương tác thành phần không được hiểu rõ ràng. Sự phức tạp bổ sung này giới thiệu lại một số vấn đề mà SOA đã tìm cách khắc phục.

Kiến trúc vi dịch vụ tương tự như các mẫu SOA trong việc sử dụng các dịch vụ chuyên dụng, liên kết lỏng lẻo. Nhưng họ còn đi xa hơn trong việc phá bỏ những kiến ​​trúc truyền thống. Các dịch vụ trong kiến ​​trúc vi dịch vụ sử dụng một khung nhắn tin chung, chẳng hạn như API RESTful. Họ sử dụng API RESTful để giao tiếp với nhau mà không cần giao dịch chuyển đổi dữ liệu khó khăn hoặc các lớp tích hợp bổ sung. Việc sử dụng API RESTful cho phép và thậm chí khuyến khích phân phối nhanh hơn các tính năng và bản cập nhật mới. Mỗi dịch vụ là rời rạc. Một dịch vụ có thể được thay thế, tăng cường hoặc loại bỏ mà không ảnh hưởng đến bất kỳ dịch vụ nào khác trong kiến ​​trúc. Kiến trúc gọn nhẹ này giúp tối ưu hóa tài nguyên đám mây hoặc phân tán và hỗ trợ khả năng mở rộng động cho các dịch vụ riêng lẻ.

Webhook là chức năng gọi lại dựa trên HTTP cho phép giao tiếp nhẹ, theo sự kiện giữa 2 API. Webhook được nhiều ứng dụng web sử dụng để nhận một lượng nhỏ dữ liệu từ các ứng dụng khác, nhưng webhook cũng có thể được sử dụng để kích hoạt quy trình làm việc tự động hóa trong môi trường GitOps.

Webhook thường được gọi là API đảo ngược hoặc API đẩy, vì chúng đặt trách nhiệm liên lạc lên máy chủ thay vì máy khách. Thay vì máy khách gửi yêu cầu HTTP—yêu cầu dữ liệu cho đến khi máy chủ phản hồi—máy chủ sẽ gửi cho máy khách một yêu cầu HTTP POST ngay khi có sẵn dữ liệu. Bất chấp biệt hiệu của chúng, webhook không phải là API; Họ làm việc cùng nhau. Ứng dụng phải có API để sử dụng webhook. 

Source: Redhat