Tweet
thiết kế phiên bản trong rest api
THIẾT KẾ PHIÊN BẢN TRONG REST API
Vấn đề các phiên bản (version) là một phần quan trọng khi thiết kế API. Nó cho phép các lập trình viên cải tiến API mà không làm hỏng các ứng dụng khi có một cập nhật mới được triển khai. Có bốn chiến lược thường được triển khai để giải quyết vấn đề phiên bản trong API:
Khi có một yêu cầu truy cập đến một danh sách, chúng ta không cần thiết hiển thị tất cả các tài nguyên cùng lúc. Lúc này chúng ta cần cơ chế phân trang. Có hai giải pháp tiêu biểu cho việc phân trang:
Một giải pháp đơn giản cho việc phân trang dùng độ lệch là dùng các thông số offset và limit. Các thông số này là quen thuộc trong các cơ sở dữ liệu. Thông thường thì các kết quả trả về từ dịch vụ sẽ có các kết nối đến các trang kế tiếp và trang trước đó.
GET /devices?offset=100&limit=10
{
"pagination": {
"offset": 100,
"limit": 10,
"total": 220,
},
"device": [
//...
],
"links": {
"next": "http://myhouse.cisco.com/devices?
offset=110&limit=10",
"prev": "http://myhouse.cisco.com/devices?
offset=90&limit=10"
}
}
Khống chế tốc độ và vấn đề tính cước
Khống chế tốc độ là một phương pháp thiết kế cơ bản API. Các kỹ thuật khống chế tốc độ được dùng để tăng tính bảo mật và hiệu quả.
Khống chế lưu lượng ở phía client: Khi chúng ta viết code cho phần mềm phía client, bạn nên xem xét các yếu tố như:
Vấn đề các phiên bản (version) là một phần quan trọng khi thiết kế API. Nó cho phép các lập trình viên cải tiến API mà không làm hỏng các ứng dụng khi có một cập nhật mới được triển khai. Có bốn chiến lược thường được triển khai để giải quyết vấn đề phiên bản trong API:
- URI path versioning: trong chiến lược này, chỉ số phiên bản sẽ được bao gồm trong địa chỉ URL.
- Query parameter versioning: Trong chiến lược này, phiên bản được gửi như là một thông số truy vấn trong URL.
- Custom headers: Các REST API được đánh phiên bản bằng cách cung cấp các header tùy biến trong đó số phiên bản là một thuộc tính. Sự khác nhau giữa giải pháp này và giải pháp trước là nó không làm lộn xộn phần URI với các thông tin về version.
- Content negotiation: Chiến lược này cho phép bạn nâng cấp phiên bản của một tài nguyên đơn lẻ thay vì đánh phiên bản cho toàn bộ API. Cách này giúp bạn kiểm soát chi tiết hơn. Một lợi điểm của giải pháp này là nó không yêu cầu bạn hiện thực các luật định tuyến dựa trên URI.
Khi có một yêu cầu truy cập đến một danh sách, chúng ta không cần thiết hiển thị tất cả các tài nguyên cùng lúc. Lúc này chúng ta cần cơ chế phân trang. Có hai giải pháp tiêu biểu cho việc phân trang:
- Phân trang dựa theo độ lệch hay khoảng cách (offset-based)
- Phân trang dựa theo từ khóa hay con trỏ (chúng ta được khuyến cáo dùng cách này).
Một giải pháp đơn giản cho việc phân trang dùng độ lệch là dùng các thông số offset và limit. Các thông số này là quen thuộc trong các cơ sở dữ liệu. Thông thường thì các kết quả trả về từ dịch vụ sẽ có các kết nối đến các trang kế tiếp và trang trước đó.
GET /devices?offset=100&limit=10
{
"pagination": {
"offset": 100,
"limit": 10,
"total": 220,
},
"device": [
//...
],
"links": {
"next": "http://myhouse.cisco.com/devices?
offset=110&limit=10",
"prev": "http://myhouse.cisco.com/devices?
offset=90&limit=10"
}
}
Khống chế tốc độ và vấn đề tính cước
Khống chế tốc độ là một phương pháp thiết kế cơ bản API. Các kỹ thuật khống chế tốc độ được dùng để tăng tính bảo mật và hiệu quả.
- Đối với vấn đề bảo mật: cho phép truy cập không giới hạn đến các API thì giống như giao chìa khóa nhà cho kẻ trộm. Mở rộng truy cập đến API có thể làm giảm giá trị và ảnh hưởng đến kinh doanh. Khống chế tốc độ truy cập API là một yếu tố quan trọng đối với việc mở rộng API. Các giới hạn xử lý thường được đo lường theo đơn vị số giao dịch trên một giây (transactions per second – TPS). Nếu một người dùng gửi quá nhiều truy cập API, các kỹ thuật khống chế tốc độ có thể hạn chế số kết nối thay vì hủy kết nối. Kỹ thuật này sẽ giúp các khách hàng vẫn sử dụng dịch vụ của bạn trong khi bạn vẫn bảo vệ được API. Cuối cùng, hãy nhớ rằng vẫn có một rủi ro là các API bị hết thời gian và các kết nối mở có thể gia tăng khả năng bị DDOS.
- Ảnh hưởng đến kinh doanh: Một cách tiếp cận khác đối với khống chế tốc độ truy cập API là cung cấp hai gói dịch vụ khác nhau: một gói miễn phí và một gói premium. Các giới hạn có thể theo số lượng session hay số lượng API được sử dụng mỗi ngày hay mỗi tháng. Có nhiều yếu tố để xem xét khi quyết định sẽ tính cước như thế nào đối với truy cập theo gói premium. Các đơn vị cung cấp dịch vụ thông qua API cần phải xem xét các yếu tố như: các yêu cầu gọi API có bị khống chế khi nó vượt quá giới hạn, các cuộc gọi mới và các yêu cầu API có chịu thêm các cước phát sinh? Các lần gọi API mới có nhận thêm mã lỗi đặc biệt hay không? Và nếu có thì dùng mã nào?
- Tính hiệu quả: Các lần gọi API không được điều chỉnh có thể dẫn đến tình trạng tải các trang bị chậm trên các websites. Điều này không chỉ làm cho khách hàng cảm thấy không hài lòng mà còn làm giảm thứ hạng dịch vụ của bạn.
Khống chế lưu lượng ở phía client: Khi chúng ta viết code cho phần mềm phía client, bạn nên xem xét các yếu tố như:
- Tránh sử dụng các cơ chế truy xuất dữ liệu liên tục dùng webhook để kích hoạt các cập nhật. Lưu trữ cache các dữ liệu chính khi bạn cần lưu các giá trị đặc biệt hay xem xét nhanh các tập dữ liệu lớn.
- Truy vấn với các bộ lọc đặc biệt.
- Tải về các dữ liệu vào giờ cao điểm.