Tweet
Hình này làm rõ hơn bản chất của API (Application Programming Interface) và tại sao API trở thành nền tảng của Network Automation.
API là gì?
API có thể hiểu là một giao diện được một hệ thống cung cấp ra bên ngoài, cho phép phần mềm khác sử dụng một số chức năng hoặc dữ liệu của hệ thống đó mà không cần biết cách nó được xây dựng bên trong.
Nói đơn giản:
API = cách để hai phần mềm "nói chuyện" với nhau.
Hình ổ cắm điện trên slide là một phép so sánh khá hay. Khi sử dụng ổ cắm, chúng ta không cần biết hệ thống điện phía sau tường hoạt động thế nào. Chỉ cần tuân thủ đúng "giao diện" đã quy định.
API cũng tương tự:
Application A → API → Application B
Application A gửi Request, API chuyển yêu cầu tới Application B và dữ liệu/kết quả được trả về dưới dạng Response.
Một API thường quy định những gì?
API không chỉ đơn giản là một địa chỉ để truy cập. Nó còn xác định cách hai hệ thống giao tiếp.
Transport xác định phương thức vận chuyển dữ liệu. Ví dụ REST API thường sử dụng HTTP/HTTPS.
Request–Response Mechanism xác định cách gửi yêu cầu và nhận kết quả. Với REST API, chúng ta thường gặp:
GET → đọc dữ liệu
POST → tạo mới
PUT → cập nhật/thay thế
PATCH → chỉnh sửa
DELETE → xóa
Ví dụ:
GET /interfaces
có thể được sử dụng để yêu cầu thiết bị trả về danh sách interface.
State Requirements xác định API có cần lưu trạng thái của phiên giao tiếp hay không. REST nổi tiếng với nguyên tắc stateless: mỗi request nên chứa đủ thông tin cần thiết để server xử lý mà không phụ thuộc vào trạng thái của request trước.
Từ API đến Device API
Trong Network Automation, một router, switch hay firewall cũng có thể cung cấp API.
Khi đó chúng ta thường gọi là Device API.
Thay vì:
Engineer
↓
SSH
↓
CLI
↓
Switch
chúng ta có thể:
Python / Ansible / Controller
↓
Device API
↓
Router / Switch
Ví dụ một chương trình có thể yêu cầu:
GET /interfaces
để lấy trạng thái interface, hoặc gửi yêu cầu thay đổi configuration mà không cần engineer đăng nhập SSH và gõ từng câu lệnh.
Trong môi trường mạng hiện đại, chúng ta sẽ thường xuyên gặp các cơ chế như:
REST API, RESTCONF, NETCONF, gNMI/gRPC và YANG data models.
API quan trọng thế nào đối với Automation?
Giả sử doanh nghiệp có 200 switch và cần tạo VLAN 100.
Cách truyền thống:
SSH Switch01 → configure
SSH Switch02 → configure
SSH Switch03 → configure
...
SSH Switch200 → configure
Với Automation:
Automation Platform
↓
API
↓
Switch01
Switch02
Switch03
...
Switch200
Một chương trình có thể tự động thực hiện công việc trên toàn bộ hệ thống.
Đây là lý do API rất quan trọng đối với Network Programmability, SDN, Infrastructure as Code và Network Automation.
Có thể nhớ bằng một chuỗi rất đơn giản:
API giúp máy nói chuyện với máy → Device API giúp phần mềm nói chuyện với thiết bị mạng → Automation sử dụng các API đó để quản lý hạ tầng ở quy mô lớn.
Vì vậy, khi học Network Automation, điều quan trọng không còn chỉ là biết "gõ CLI như thế nào", mà còn phải hiểu "làm thế nào để phần mềm thực hiện công việc đó thay cho chúng ta".
API là gì?
API có thể hiểu là một giao diện được một hệ thống cung cấp ra bên ngoài, cho phép phần mềm khác sử dụng một số chức năng hoặc dữ liệu của hệ thống đó mà không cần biết cách nó được xây dựng bên trong.
Nói đơn giản:
API = cách để hai phần mềm "nói chuyện" với nhau.
Hình ổ cắm điện trên slide là một phép so sánh khá hay. Khi sử dụng ổ cắm, chúng ta không cần biết hệ thống điện phía sau tường hoạt động thế nào. Chỉ cần tuân thủ đúng "giao diện" đã quy định.
API cũng tương tự:
Application A → API → Application B
Application A gửi Request, API chuyển yêu cầu tới Application B và dữ liệu/kết quả được trả về dưới dạng Response.
Một API thường quy định những gì?
API không chỉ đơn giản là một địa chỉ để truy cập. Nó còn xác định cách hai hệ thống giao tiếp.
Transport xác định phương thức vận chuyển dữ liệu. Ví dụ REST API thường sử dụng HTTP/HTTPS.
Request–Response Mechanism xác định cách gửi yêu cầu và nhận kết quả. Với REST API, chúng ta thường gặp:
GET → đọc dữ liệu
POST → tạo mới
PUT → cập nhật/thay thế
PATCH → chỉnh sửa
DELETE → xóa
Ví dụ:
GET /interfaces
có thể được sử dụng để yêu cầu thiết bị trả về danh sách interface.
State Requirements xác định API có cần lưu trạng thái của phiên giao tiếp hay không. REST nổi tiếng với nguyên tắc stateless: mỗi request nên chứa đủ thông tin cần thiết để server xử lý mà không phụ thuộc vào trạng thái của request trước.
Từ API đến Device API
Trong Network Automation, một router, switch hay firewall cũng có thể cung cấp API.
Khi đó chúng ta thường gọi là Device API.
Thay vì:
Engineer
↓
SSH
↓
CLI
↓
Switch
chúng ta có thể:
Python / Ansible / Controller
↓
Device API
↓
Router / Switch
Ví dụ một chương trình có thể yêu cầu:
GET /interfaces
để lấy trạng thái interface, hoặc gửi yêu cầu thay đổi configuration mà không cần engineer đăng nhập SSH và gõ từng câu lệnh.
Trong môi trường mạng hiện đại, chúng ta sẽ thường xuyên gặp các cơ chế như:
REST API, RESTCONF, NETCONF, gNMI/gRPC và YANG data models.
API quan trọng thế nào đối với Automation?
Giả sử doanh nghiệp có 200 switch và cần tạo VLAN 100.
Cách truyền thống:
SSH Switch01 → configure
SSH Switch02 → configure
SSH Switch03 → configure
...
SSH Switch200 → configure
Với Automation:
Automation Platform
↓
API
↓
Switch01
Switch02
Switch03
...
Switch200
Một chương trình có thể tự động thực hiện công việc trên toàn bộ hệ thống.
Đây là lý do API rất quan trọng đối với Network Programmability, SDN, Infrastructure as Code và Network Automation.
Có thể nhớ bằng một chuỗi rất đơn giản:
API giúp máy nói chuyện với máy → Device API giúp phần mềm nói chuyện với thiết bị mạng → Automation sử dụng các API đó để quản lý hạ tầng ở quy mô lớn.
Vì vậy, khi học Network Automation, điều quan trọng không còn chỉ là biết "gõ CLI như thế nào", mà còn phải hiểu "làm thế nào để phần mềm thực hiện công việc đó thay cho chúng ta".
Attached Files