CHƯƠNG 4: GIAO TIẾP LẬP TRÌNH ỨNG DỤNG API - - VnPro

CHƯƠNG 4: GIAO TIẾP LẬP TRÌNH ỨNG DỤNG API

API là nền tảng quan trọng cho một thế hệ mới các phần mềm trong lĩnh vực mạng, điện toán đám mây (cloud), lĩnh vực di động mobile và Internet của vạn vật IoT. API kết nối các phần mềm lại với nhau, cho phép hai phần mềm giao tiếp, tương tác với nhau.

Các nhà phát triển phần mềm cũng dùng API để cho phép các phần mềm giao tiếp với hạ tầng mạng. Chúng ta có thể dùng API để cấu hình và giám sát các thành phần cụ thể của một hạ tầng mạng. Có nhiều loại API. Chương này tập trung vào hai loại API phổ biến nhất trong kiến trúc SDN: northbound API và southbound API. Bài viết giới thiệu về API dưới góc nhìn của lĩnh vực tự động trong hạ tầng mạng network automation.

Tóm tắt: API là một giao tiếp cho phép phần mềm tương tác, giao tiếp với phần mềm.

4.1. Phân loại API

API có thể chia thành ba nhóm, dựa trên ba loại công việc mà API thực hiện.

• API dịch vụ (Service API): Trong loại API này, một ứng dụng có thể gọi một ứng dụng khác để giải quyết một vấn đề cụ thể. Thường thì các hệ thống này có thể tồn tại độc lập với nhau. Ví dụ, trong một hệ thống thanh toán, một ứng dụng có thể gọi API để chấp nhận một thanh toán dùng thẻ tín dụng. Một ví dụ khác là với hệ thống quản lý người dùng, một ứng dụng có thể gọi một API để kiểm tra và xác thực người dùng. Hình vẽ bên dưới minh họa cách App1 sử dụng API trong các chức năng thanh toán, quản lý người dùng, quản lý các mạng xã hội.

• API cung cấp thông tin (Information API): Cho phép một ứng dụng hỏi một ứng dụng khác về một thông tin nào đó. Thông tin trong ngữ cảnh này có thể muốn ám chỉ đến các dữ liệu được thu thập trong một thời gian dài, các dữ liệu từ xa telemetry hay danh sách của một số thiết bị đang kết nối vào hệ thống mạng.

• API phần cứng (Hardware API): Một số nhà phát triển ứng dụng có thể dùng các API phần cứng này để truy cập đến một số tính năng của thiết bị phần cứng. Thông thường các API bao gồm một vài thiết bị phần cứng hay các cảm biến sensor. Một ứng dụng có thể gọi kiểu API này để truy xuất vị trí GPS hay các dữ liệu thời gian thực khác như nhiệt độ hay độ ẩm.

Tóm tắt: có ba loại API là API cung cấp một dịch vụ, API cung cấp thông tin và các API truy cập phần cứng.

4.2. Các kiểu truy cập API

Một cách tiêu biểu, chúng ta có ba kiểu truy cập và sử dụng API

• Kiểu riêng (private): API dạng này chỉ được sử dụng nội bộ. Kiểu truy cập này sẽ cho phép doanh nghiệp kiểm soát toàn bộ API của họ.
• Kiểu đối tác (partner): Kiểu API này được dùng để chia sẻ với các đối tác kinh doanh. Kiểu này có thể tạo ra các dòng giá trị lợi nhuận mà không làm giảm chất lượng.
• Kiểu công cộng (public): Kiểu API công cộng thì sẵn sàng cho mọi người sử dụng. Loại API này cho phép các bên thứ ba phát triển các ứng dụng giao tiếp với API và có thể là một nguồn để tăng tính sáng tạo, đổi mới.

Bất chấp các API được truy cập như thế nào, các API được thiết kế để tương tác thông qua một hạ tầng mạng. Và bởi vì phần lớn các giao tiếp mạng ngày nay dùng Internet, phần lớn các cuộc gọi API được thiết kế dựa trên chuẩn web.

Do đặc điểm độc đáo của HTTP trên web, phần lớn các nhà phát triển ứng dụng đã dùng HTTP như là giao thức bên dưới cho các API của họ. Lợi ích lớn nhất của việc sử dụng HTTP là nó giảm thiểu việc học hỏi thêm về HTTP do HTTP quá phổ biến. HTTP có vài đặc điểm rất hữu ích khi chúng ta xây dựng API.

Tóm tắt: Phần lớn các API sử dụng HTTP như giao thức ở truyền vận bên dưới.

4.3. Northbound APIs

Các API loại này thường được dùng trong quá trình giao tiếp từ một bộ điều khiển mạng network controller hướng lên phần mềm quản lý bên trên. Giả sử chúng ta lấy thiết bị controller làm trung tâm, nếu chúng ta đi về phía bên trên (phía bắc), chúng ta sẽ gặp các phần mềm ứng dụng ở hướng đó. Giao tiếp API trong tình huống này được phân loại như là northbound API.

Ví dụ: Phần mềm Cisco DNA Center có một giao diện đồ họa GUI cho phép chúng ta quản lý chính nó. Khi một nhân viên quản trị mạng login vào DNA để quản lý hạ tầng mạng, các thông tin sẽ được gửi từ phần mềm quản lý đến controller thông qua northbound API. Chúng ta còn gọi kiểu API này như là REST API. Các kinh nghiệm thực tế cho thấy các lưu lượng mạng loại này nên được mã hóa bằng giao thức TLS giữa phần mềm và controller. Phần lớn các API đều có khả năng dùng các thuật toán mã hóa để bảo vệ dữ liệu đang luân chuyển.

4.4. Southbound APIs

Từ controller, nếu một bạn quản trị đang thay đổi cấu hình của một switch, các thay đổi này sẽ được đẩy từ controller xuống switch. Dạng API này gọi là southbound API do chiều gọi API là từ controller đi xuống thiết bị. Trong hạ tầng mạng, chúng ta có nhiều loại thiết bị như routers, switch, wireless access point AP.

API có thể được dùng để thay đổi nhiều chức năng của thiết bị, chứ không chỉ là thay đổi các chức năng dữ liệu data plane. (Chức năng luân chuyển dữ liệu giữa các cổng của thiết bị và tất cả các hoạt động khác liên quan đến định dạng dữ liệu, nén, mã hóa, kiểm soát lỗi…)

Tóm tắt: Một giao tiếp northbound là một giao tiếp cho phép một thành phần của hạ tầng mạng giao tiếp với các thành phần ở lớp cao hơn. Một cách tương ứng, một giao tiếp southbound cho phép một thành phần mạng giao tiếp với một thành phần ở lớp thấp hơn.

4.5. APIs: đồng bộ và bất đồng bộ

API có thể quản lý các phiên giao tiếp theo kiểu đồng bộ hoặc bất đồng bộ. Một phần mềm ứng dụng dùng API kiểu đồng bộ sẽ phải chờ phản hồi từ API server để có thể tiếp tục xử lý dữ liệu hay hoạt động bình thường. Điều này có thể dẫn đến sự ngắt quãng trong tiến trình xử lý hoặc làm tăng độ trễ, thậm chí là treo ứng dụng.

Ví dụ, khi chúng ta upload các video lên youtube, chúng ta không thể sử dụng giao diện GUI hoặc thay đổi tên của video hoặc thực thi các thay đổi khác. Người dùng phải chờ cho tới khi tiến trình upload hoàn tất để có thể làm các tác vụ khác bên trong ứng dụng Youtube.

API hoạt động theo kiểu bất đồng bộ asynchronous APIs sẽ làm hoàn toàn trái ngược với kiểu API đồng bộ. Lúc này, các phần mềm sẽ không chờ API trả về kết quả mà sẽ tiếp tục hoạt động và xử lý các chức năng dữ liệu khác. API kiểu bất đồng bộ này cung cấp một chức năng gọi lại (callback) sao cho các trả lời của API có thể gửi lại ở bất kỳ thời điểm nào. Phần mềm lúc này không cần phải chờ cho phiên gọi API hoàn tất.

Với ví dụ youtube bên trên, nếu chúng ta sử dụng API bất đồng bộ, chúng ta có thể thay đổi tựa đề, thêm vào các hashtag, hoặc thậm chí nhận luôn địa chỉ URL của video trong khi video đang được tải lên.

Tóm tắt: sự khác biệt giữa API kiểu đồng bộ và bất đồng bộ là API kiểu đồng bộ sẽ chờ cho phần đoạn chương trình đó thực thi xong trước khi đi qua đoạn chương trình khác. Kiểu API bất đồng bộ thì có khả năng tiếp tục xử lý chương trình (code) và cung cấp chức năng gọi lại sao cho một không phải chờ kết quả từ API. Các phần mềm sử dụng gọi API kiểu bất đồng bộ sẽ cho người dùng trải nghiệm tốt hơn.

4.6. REST APIs

REST API ngày càng trở nên phổ biến và được sử dụng nhiều trong ngành công nghiệp mạng, măc dù kiểu kiến trúc REST đã có từ những năm 2000. Hầu hết các kiểu API hiện có trong hạ tầng mạng là kiểu REST API. Điều này có nghĩa là nếu bạn nghe nói đến một thiết bị hay một SDN controller có hỗ trợ API, thì loại API đó là một giao tiếp theo mô hình client-server. Phía client có thể là một phần mềm ứng dụng chẳng hạn như một chương trình Python hoặc một giao diện web. Phía máy chủ server có thể là một thiết bị mạng hoặc là một bộ điều khiển mạng controller.

Một API sử dụng kiến trúc REST thường được gọi là RESTful API. Kiến trúc REST thường được mô tả chung như là một kiến trúc theo mô hình client-server, phi trạng thái (stateless). Các Restful API thường dùng giao thức HTTP và các phương thức của HTTP để thu thập và thao tác các dữ liệu.

Trong hình minh họa bên dưới, sự khác nhau nằm ở định dạng dữ liệu được gửi vào và ra của máy chủ web. Khi chúng ta duyệt Internet, chúng ta sẽ nhận được các dữ liệu HTML, sau đó các trình duyệt sẽ hiện thị các nội dung này. Còn khi chúng ta thực thi một hàm gọi HTTP GET đến một máy chủ đang cung cấp chức năng của nó thông qua RESTful API, chúng ta sẽ nhận lại được kết quả trả về ở dạng JSON hay XML. Lúc này, các máy client phải hiểu và diễn dịch được các định dạng dữ liệu JSON hay XML.

Vì HTTP được dùng như một giao thức truyền vận, khi chúng ta gọi API, chúng ta cũng thực hiện các tác vụ sử dụng URL cũng giống như khi chúng ta duyệt World Wide Web. Khi chúng ta truy cập đến một website, phương thức HTTP GET được được thực hiện. Nếu chúng ta điền vào một biểu mẫu trên web và nhấn nút Submit, một phương thức HTTP POST đang được thực thi. RESTful API cũng hoạt động cơ bản giống như vậy.

Chúng ta ít nhiều đều đã nghe nói đến giao thức HTTP hoặc đã biết về cách thức HTTP hoạt động. Hoạt động của HTTP thường theo cấu trúc được định nghĩa chặt chẽ, nhất quán. Chính vì vậy HTTP cung cấp một phương thức nhất quán để gọi API từ các thiết bị khác nhau của các nhà cung cấp khác nhau.

Kiến trúc REST sử dụng các chức năng có sẵn của HTTP để tương tác với dữ liệu.

Các chức năng của HTTP tương tự như các chức năng mà phần lớn các ứng dụng và các cơ sở dữ liệu dùng để lưu trữ và thay đổi dữ liệu. Các chức năng này được gọi là CRUD, viết tắt của CREATE, READ, UPDATE, DELETE.

Tóm tắt: RESTful API là một kiểu kiến trúc cho API trong đó dùng các phương thức HTTP requests để truy cập và sử dụng dữ liệu. Các dữ liệu đó có thể được dùng thông qua các hành động như GET, PUT, POST và DELETE. Các hành động này để chỉ đến việc đọc, cập nhật, tạo mới và xóa các tài nguyên trên hệ thống.

4.7. Simple Object Access Protocol (SOAP)

SOAP thường được dùng để truy cập các dịch vụ web. Mặc dù HTTP là giao thức lớp transport phổ biến nhất, SOAP vẫn có thể sử dụng SMTP như là giao thức cho lớp transport. SOAP thường được dùng để trao đổi dữ liệu giữa các ứng dụng được viết bằng cách ngôn ngữ lập trình khác nhau như Java, .NET, PHP. SOAP có thể trao đổi toàn bộ tài liệu hay thực thi một RPC. Trong một số ứng dụng, SOAP cũng được dùng để phát tán kiểu broadcast các thông điệp.

Điểm mạnh của giao thức SOAP là nó cho phép các ứng dụng client có thể kết nối dễ dàng để các dịch vụ ở xa và kích hoạt các phương thức. SOAP đơn giản hóa công việc của một người lập trình. Nó giúp trao đổi dữ liệu giữa các ứng dụng theo cách đơn giản hóa. SOAP dùng định dạng dữ liệu XML. Hình bên dưới so sánh SOAP và REST.

Phần lớn các ngôn ngữ lập trình ngày nay đều có các thư viện để làm việc với định dạng XML, do đó SOAP có thể hoạt động như một giao tiếp trung gian giữa các ứng dụng khác nhau. SOAP dùng định dạng XML để giao tiếp giữa các dịch vụ web và clients. Bởi vì SOAP độc lập với hệ điều hành, nó có thể dùng trên Windows và cả Linux.

Các loại thông điệp (messages) mà SOAP dùng để gửi giữa client và server bao gồm các thành phần sau: Envelope, Header, Body, Fault (optional). Hình vẽ bên dưới mô tả các thành phần của một thông điệp mà SOAP sử dụng.

Phần envelope sẽ đóng gói các dữ liệu dạng XML và giúp các ứng dụng xác định đây là một thông điệp của SOAP. Phần này cũng sẽ chỉ ra phần bắt đầu và kết thúc của một thông điệp SOAP.

Phần kế tiếp trong thông điệp SOAP là SOAP header, phần này chứa nhiều header blocks. Các header block được dùng để gửi đến các máy nhận SOAP. Nếu một SOAP có một header, phần header phải nằm trên phần thân (body).

Phần thân của thông điệp SOAP chứa các thông điệp thật sự mà bên kia cần nhận. Nếu mỗi một thông điệp SOAP chứa một header, nó phải chứa một phần thân body. Thông thường, các thông điệp SOAP này được tự động tạo ra khi có một client gọi đến các dịch vụ web.

Một lợi ích tiềm năng khác của SOAP là nó dùng HTTP như là giao thức cho phần truyền dẫn. Do đó SOAP có thể đi xuyên qua các tường lửa mà không cần các cổng mở thêm trên tường lửa. Điều này giúp chúng ta tiết kiệm thời gian. Điểm mạnh của SOAP là khả năng làm việc với các ngôn ngữ lập trình khác nhau, trong khi vẫn duy trì cách định dạng chung của XML hay các đặc tính đơn giản của giao thức truyền vận HTTP.

Hiệp hội W3C khuyến cáo chúng ta sử dụng đặc tả của phiên bản SOAP hiện tại (phiên bản 1.2). SOAP cũng có tùy chọn cho các thông điệp cảnh báo lỗi.

Tóm tắt: SOAP là một giao thức sử dụng định dạng dữ liệu XML để truyền các thông điệp giữa các máy tính. SOAP là một ứng dụng của đặc tả dữ liệu XML. Đây là một giao thức được thiết kế để sử dụng trên Internet. Nó có thể tận dụng HTTP để gửi các dữ liệu dưới định dạng XML.

4.8. Gọi hàm/thủ tục từ xa (Remote-Procedure Calls - RPCs)

RPC cho phép chúng ta thực thi những đoạn mã hay thực thi chương trình trên một máy ở xa trong hệ thống mạng. RPC hoạt động như thể đoạn chương trình được thực thi cục bộ. Phần lớn các cuộc gọi remote hoặc local đều giống nhau về bản chất và có thể phân biệt với nhau dựa trên một máy là cục bộ (local) hay ở xa (remote).

Sử dụng RPC là một cách rất phổ biến để chương trình chúng ta thực thi một lệnh cụ thể nào đó, chẳng hạn như thực thi tác vụ GET hay POST để thiết lập API hay một URL.

Khi một client gửi một yêu cầu request, RPC sẽ diễn dịch yêu cầu đó và gửi nó đến máy chủ. Một request có thể là một thủ tục procedure hay một gọi hàm trên một máy ở xa. Khi máy chủ nhận được yêu cầu, nó sẽ gửi lại các trả lời cho máy client. Khi các hoạt động tương tác này đang diễn ra, phía client sẽ bị chặn lại không cho gửi các request kế tiếp. Điều này cho phép các máy chủ có thời gian để xử lý yêu cầu. Khi cuộc gọi RPC được xử lý và hoàn tất, một kết quả đã được trả về cho client. Hoạt động giao tiếp giữa client/server sẽ được tiếp tục. Cơ chế này được xem như một cách bảo vệ đơn giản để tránh các cuộc gọi RPC tràn ngập máy chủ, gây ra tình trạng DoS hay cạn kiệt tài nguyên.

Có vài phiên bản của các thông điệp RPC. Tuy nhiên dạng phổ biến nhất là XML-RPC. Dạng XML-RPC là dạng phổ biến nhất trước khi có SOAP.

Trong ví dụ trên, chúng ta có thể thấy định dạng của XML thì rất giống với định dạng dùng trong SOAP. Các định dạng này giúp cho cả người và máy đều có thể đọc, hiểu và có thể xây dựng được. Ví dụ bên dưới là một ví dụ của kết quả trả về của tác vụ GET nêu trên.

Các API hoạt động theo kiểu RPC thì phù hợp cho các hành động. Các API theo kiểu REST thì phù hợp với các mô hình (ví dụ như các tài nguyên, các đối tượng) hoặc các thao tác CRUD trên các dữ liệu.

RPC thường chỉ dùng GET và POST, trong đó GET được dùng để nạp dữ liệu và POST được dùng cho tất cả mọi việc còn lại. Sự khác nhau giữa REST và RPC thể hiện trong ví dụ bên dưới.

RPC API để xóa sẽ có dạng POST /deleteFoo, trong đó phần thân của hàm sẽ là {“id”: 1}, trong khi với REST sẽ là DELETE /foos/1. Trong RPC, mọi thứ sẽ là POST /dowhateverThingNow.

Tóm tắt: RPC là dạng đầu tiên và đơn giản nhất của API. Chức năng của nó là thực thi một đoạn mã trên một máy chủ khác. Nếu hiện thực RPC bằng HTTP, chúng ta có WebAPI.

Đặng Quang Minh

Email: dangquangminh@vnpro.org

Thông tin khác

• » LAB 18: Thực thi chính sách QoS trong Cisco SD-WAN (08.04.2021)
• » LAB 19: Sử dụng Postman tương tác với SD-WAN REST API (08.04.2021)
• » LAB 20: Dùng Python lấy danh sách thông tin các thiết bị trong fabric SD-WAN của Cisco (08.04.2021)
• » LAB 17: Viết chính sách dữ liệu Data Policy để ảnh hưởng đến việc lựa chọn đường dẫn ưu tiên cho các ứng dụng. (05.04.2021)
• » REST-BASED APIS (05.04.2021)
• » Các bước chuẩn bị để thực hành devnet cho máy sử dụng hđh Windows, gồm 7 bước: (02.04.2021)
• » Setup WSL 1 (02.04.2021)
• » GIỚI THIỆU MÔN HỌC ADVANCED ROUTING (31.03.2021)