Tweet
Sync API và Async API – Khái niệm nền tảng mà DevOps Engineer và CCNA Automation cần hiểu
Khi học về Network Automation, DevOps, Cloud Automation hay API Integration, một trong những khái niệm nền tảng nhưng cực kỳ quan trọng là sự khác nhau giữa Synchronous API (Sync API) và Asynchronous API (Async API).
Rất nhiều người mới học automation thường chỉ tập trung vào việc:
Nhưng trong môi trường thực tế, chỉ biết “gọi API” là chưa đủ.
Điều quan trọng hơn là phải hiểu:
API này phản hồi theo mô hình nào?
Bởi vì điều này ảnh hưởng trực tiếp đến cách bạn thiết kế automation script, xử lý lỗi, retry logic, timeout, thậm chí cả kiến trúc hệ thống.
Vì sao DevOps và Network Automation phải hiểu chuyện này?
Hãy tưởng tượng bạn viết một automation script để:
Có những việc hoàn thành gần như ngay lập tức.
Nhưng cũng có những việc mất:
Nếu không hiểu mô hình API, code automation rất dễ:
Đây là lý do Sync vs Async là kiến thức nền.
Sync API là gì?
Synchronous API hoạt động theo mô hình đơn giản nhất:
Client gửi request.
Server xử lý.
Server trả kết quả.
Client chờ cho đến khi nhận response.
Luồng hoạt động:
Client → Request → Server
Client ← Response ← Server
Đây là kiểu giao tiếp “hỏi và trả lời ngay”.
Ví dụ:
Bạn gọi API lấy danh sách thiết bị từ Cisco controller:
GET /dna/intent/api/v1/network-device
Server trả về:
{
"response": [
{
"hostname": "SW1",
"managementIpAddress": "10.10.10.10"
}
]
}
Dữ liệu đã có ngay trong response.
Không cần gọi thêm API nào khác.
Ví dụ đời thường
Hãy tưởng tượng bạn gọi điện hỏi lễ tân khách sạn:
Lễ tân kiểm tra hệ thống.
Trả lời ngay:
Đó là Sync.
Bạn hỏi.
Họ trả lời.
Kết thúc.
Đặc điểm của Sync API
Sync API phù hợp khi công việc xử lý nhanh.
Ví dụ:
Trong DevOps:
Lấy trạng thái pod Kubernetes:
kubectl get pods
REST API:
GET /api/users
Prometheus:
GET /api/v1/query
Trong Network Automation:
RESTCONF:
GET /restconf/data/Cisco-IOS-XE-native:native
Lấy routing table:
GET /restconf/data/Cisco-IOS-XE-routing:routing-state
Ưu điểm của Sync API
Mô hình này dễ hiểu.
Dễ code.
Dễ debug.
Python code thường rất đơn giản:
import requests
response = requests.get(url, headers=headers)
data = response.json()
Không cần:
Rất phù hợp cho người mới học CCNA Automation.
Nhược điểm của Sync API
Vấn đề xuất hiện khi công việc xử lý lâu.
Ví dụ:
deploy cấu hình cho hàng trăm thiết bị.
Provision site mới.
Push software image.
Run CI/CD pipeline.
Terraform provisioning.
Nếu server mất 2 phút để xử lý, client phải chờ.
waiting...
waiting...
waiting...
Khi đó:
HTTP session bị giữ mở.
Resource bị chiếm dụng.
Có nguy cơ timeout.
Ví dụ:
504 Gateway Timeout
Async API là gì?
Async API xử lý khác hoàn toàn.
Client gửi request.
Server nhận request.
Nhưng không xử lý xong ngay.
Thay vào đó server trả về:
Ví dụ:
POST /dna/intent/api/v1/site
Server trả:
{
"executionId": "abc123",
"status": "scheduled"
}
Điều này có nghĩa:
Server nói:
Luồng Async
Client → Request → Server
Client ← Task ID ← Server
Client → Status Request → Server
Client ← Status ← Server
Client → Status Request → Server
Client ← Completed Result ← Server
Ví dụ đời thường
Bạn đặt mua 50 server cho data center.
Nhà cung cấp không thể giao ngay.
Họ trả:
Bạn kiểm tra sau:
Processing
Packing
Shipping
Delivered
Đây chính là Async.
Tại sao Async API rất quan trọng trong DevOps?
Trong DevOps, rất nhiều tác vụ là long-running operations.
Ví dụ:
CI/CD pipeline:
build
test
security scan
package
deploy
Terraform:
terraform apply
Cloud provisioning:
Kubernetes:
Ansible Tower:
Các tác vụ này không thể trả kết quả ngay.
Network Automation cũng dùng Async rất nhiều
Nhiều người nghĩ network API chỉ là GET configuration.
Thực tế không phải.
Ví dụ Cisco DNA Center:
Các tác vụ này backend cần:
Có thể mất nhiều thời gian.
Nên controller dùng Async.
DevOps Engineer phải code khác như thế nào?
Nếu Sync:
response = requests.get(url)
print(response.json())
Nếu Async:
Bước 1:
response = requests.post(url)
task_id = response.json()["executionId"]
Bước 2:
Polling:
while True:
status = requests.get(task_url).json()
if status["state"] == "COMPLETED":
break
Những thứ phải nghĩ khi xử lý Async
Timeout
Không thể polling mãi:
max_wait = 300
Retry
Nếu gặp:
429 Too Many Requests
hoặc:
503 Service Unavailable
Phải retry hợp lý.
Failure state
Task không phải lúc nào cũng thành công.
Ví dụ:
FAILED
ABORTED
PARTIAL_SUCCESS
Automation script phải xử lý.
Idempotency
Nếu request bị timeout:
Người mới thường gửi lại request.
Hậu quả:
Production incident xảy ra từ đây.
CCNA Automation cần nhớ gì?
Nếu bạn học DevNet, CCNA Automation hoặc bắt đầu Network Automation:
Hãy nhớ:
GET thường là Sync
Ví dụ:
GET interfaces
GET routes
GET device inventory
POST/PUT cho provisioning thường dễ là Async
Ví dụ:
POST template deployment
POST software upgrade
POST site provisioning
Không phải lúc nào cũng đúng, nhưng đây là pattern phổ biến.
So sánh nhanh
Sync:
Async:
Kết luận
Khi học automation, nhiều người chỉ học:
“API là GET/POST.”
Nhưng tư duy production thực tế là:
API có execution model riêng.
Một DevOps Engineer hay Network Automation Engineer trưởng thành phải luôn tự hỏi:
Đó là khác biệt giữa:
viết script demo
và
xây automation chạy production thật.
Khi học về Network Automation, DevOps, Cloud Automation hay API Integration, một trong những khái niệm nền tảng nhưng cực kỳ quan trọng là sự khác nhau giữa Synchronous API (Sync API) và Asynchronous API (Async API).
Rất nhiều người mới học automation thường chỉ tập trung vào việc:
- gọi API bằng Postman
- viết Python requests
- parse JSON
- gửi GET hoặc POST
Nhưng trong môi trường thực tế, chỉ biết “gọi API” là chưa đủ.
Điều quan trọng hơn là phải hiểu:
API này phản hồi theo mô hình nào?
Bởi vì điều này ảnh hưởng trực tiếp đến cách bạn thiết kế automation script, xử lý lỗi, retry logic, timeout, thậm chí cả kiến trúc hệ thống.
Vì sao DevOps và Network Automation phải hiểu chuyện này?
Hãy tưởng tượng bạn viết một automation script để:
- lấy danh sách interface từ router Cisco
- deploy cấu hình cho 200 switch
- trigger CI/CD pipeline
- provision infrastructure trên cloud
- tạo Kubernetes cluster
- rollout application deployment
Có những việc hoàn thành gần như ngay lập tức.
Nhưng cũng có những việc mất:
- 10 giây
- 30 giây
- vài phút
- thậm chí hàng chục phút
Nếu không hiểu mô hình API, code automation rất dễ:
- bị timeout
- treo process
- consume tài nguyên không cần thiết
- retry sai cách
- tạo duplicate request
- gây lỗi production
Đây là lý do Sync vs Async là kiến thức nền.
Sync API là gì?
Synchronous API hoạt động theo mô hình đơn giản nhất:
Client gửi request.
Server xử lý.
Server trả kết quả.
Client chờ cho đến khi nhận response.
Luồng hoạt động:
Client → Request → Server
Client ← Response ← Server
Đây là kiểu giao tiếp “hỏi và trả lời ngay”.
Ví dụ:
Bạn gọi API lấy danh sách thiết bị từ Cisco controller:
GET /dna/intent/api/v1/network-device
Server trả về:
{
"response": [
{
"hostname": "SW1",
"managementIpAddress": "10.10.10.10"
}
]
}
Dữ liệu đã có ngay trong response.
Không cần gọi thêm API nào khác.
Ví dụ đời thường
Hãy tưởng tượng bạn gọi điện hỏi lễ tân khách sạn:
“Phòng 503 còn trống không?”
Lễ tân kiểm tra hệ thống.
Trả lời ngay:
“Còn.”
Đó là Sync.
Bạn hỏi.
Họ trả lời.
Kết thúc.
Đặc điểm của Sync API
Sync API phù hợp khi công việc xử lý nhanh.
Ví dụ:
- query data
- read configuration
- health check
- inventory lookup
- telemetry retrieval
- metrics collection
Trong DevOps:
Lấy trạng thái pod Kubernetes:
kubectl get pods
REST API:
GET /api/users
Prometheus:
GET /api/v1/query
Trong Network Automation:
RESTCONF:
GET /restconf/data/Cisco-IOS-XE-native:native
Lấy routing table:
GET /restconf/data/Cisco-IOS-XE-routing:routing-state
Ưu điểm của Sync API
Mô hình này dễ hiểu.
Dễ code.
Dễ debug.
Python code thường rất đơn giản:
import requests
response = requests.get(url, headers=headers)
data = response.json()
Không cần:
- polling
- task tracking
- callback
- job monitoring
Rất phù hợp cho người mới học CCNA Automation.
Nhược điểm của Sync API
Vấn đề xuất hiện khi công việc xử lý lâu.
Ví dụ:
deploy cấu hình cho hàng trăm thiết bị.
Provision site mới.
Push software image.
Run CI/CD pipeline.
Terraform provisioning.
Nếu server mất 2 phút để xử lý, client phải chờ.
waiting...
waiting...
waiting...
Khi đó:
HTTP session bị giữ mở.
Resource bị chiếm dụng.
Có nguy cơ timeout.
Ví dụ:
504 Gateway Timeout
Async API là gì?
Async API xử lý khác hoàn toàn.
Client gửi request.
Server nhận request.
Nhưng không xử lý xong ngay.
Thay vào đó server trả về:
- task ID
- execution ID
- job reference
- status URL
Ví dụ:
POST /dna/intent/api/v1/site
Server trả:
{
"executionId": "abc123",
"status": "scheduled"
}
Điều này có nghĩa:
Server nói:
“Tôi đã nhận việc. Hãy quay lại kiểm tra sau.”
Luồng Async
Client → Request → Server
Client ← Task ID ← Server
Client → Status Request → Server
Client ← Status ← Server
Client → Status Request → Server
Client ← Completed Result ← Server
Ví dụ đời thường
Bạn đặt mua 50 server cho data center.
Nhà cung cấp không thể giao ngay.
Họ trả:
“Đơn hàng #56789 đã được ghi nhận.”
Bạn kiểm tra sau:
Processing
Packing
Shipping
Delivered
Đây chính là Async.
Tại sao Async API rất quan trọng trong DevOps?
Trong DevOps, rất nhiều tác vụ là long-running operations.
Ví dụ:
CI/CD pipeline:
build
test
security scan
package
deploy
Terraform:
terraform apply
Cloud provisioning:
- VM creation
- Load balancer deployment
- Database provisioning
Kubernetes:
- Job execution
- rollout deployment
Ansible Tower:
- launch job template
Các tác vụ này không thể trả kết quả ngay.
Network Automation cũng dùng Async rất nhiều
Nhiều người nghĩ network API chỉ là GET configuration.
Thực tế không phải.
Ví dụ Cisco DNA Center:
- template deployment
- software image upgrade
- compliance remediation
- PnP onboarding
- site creation
Các tác vụ này backend cần:
- validate input
- push workflow
- update database
- call controller services
- execute provisioning tasks
Có thể mất nhiều thời gian.
Nên controller dùng Async.
DevOps Engineer phải code khác như thế nào?
Nếu Sync:
response = requests.get(url)
print(response.json())
Nếu Async:
Bước 1:
response = requests.post(url)
task_id = response.json()["executionId"]
Bước 2:
Polling:
while True:
status = requests.get(task_url).json()
if status["state"] == "COMPLETED":
break
Những thứ phải nghĩ khi xử lý Async
Timeout
Không thể polling mãi:
max_wait = 300
Retry
Nếu gặp:
429 Too Many Requests
hoặc:
503 Service Unavailable
Phải retry hợp lý.
Failure state
Task không phải lúc nào cũng thành công.
Ví dụ:
FAILED
ABORTED
PARTIAL_SUCCESS
Automation script phải xử lý.
Idempotency
Nếu request bị timeout:
Người mới thường gửi lại request.
Hậu quả:
- duplicate deployment
- duplicate VM
- duplicate workflow
Production incident xảy ra từ đây.
CCNA Automation cần nhớ gì?
Nếu bạn học DevNet, CCNA Automation hoặc bắt đầu Network Automation:
Hãy nhớ:
GET thường là Sync
Ví dụ:
GET interfaces
GET routes
GET device inventory
POST/PUT cho provisioning thường dễ là Async
Ví dụ:
POST template deployment
POST software upgrade
POST site provisioning
Không phải lúc nào cũng đúng, nhưng đây là pattern phổ biến.
So sánh nhanh
Sync:
- đơn giản
- immediate response
- blocking
- phù hợp tác vụ nhanh
Async:
- scalable
- non-blocking
- cần task tracking
- phù hợp tác vụ dài
Kết luận
Khi học automation, nhiều người chỉ học:
“API là GET/POST.”
Nhưng tư duy production thực tế là:
API có execution model riêng.
Một DevOps Engineer hay Network Automation Engineer trưởng thành phải luôn tự hỏi:
- API này sync hay async?
- Có timeout không?
- Có task ID không?
- Polling ra sao?
- Retry thế nào?
- Failure handling thế nào?
Đó là khác biệt giữa:
viết script demo
và
xây automation chạy production thật.