Tweet
REST API và HTTP
API tồn tại để cho phép hai chương trình trao đổi dữ liệu. Một số API có thể được thiết kế như một giao thức giữa các chương trình chạy trên cùng một máy tính, vì vậy giao tiếp giữa các chương trình xảy ra trong một hệ điều hành đơn. Nhiều API cần phải có sẵn đến các chương trình chạy trên các máy tính khác, vì vậy API phải xác định loại giao thức mạng được hỗ trợ bởi API và nhiều API dựa trên REST sử dụng HTTP.
Những người tạo REST API thường chọn HTTP bởi vì HTTP phù hợp với một số khái niệm được định nghĩa chung cho REST API. HTTP sử dụng nguyên tắc tương tự như REST: nó hoạt động với mô hình máy khách / máy chủ; nó sử dụng một mô hình hoạt động phi trạng thái; và nó bao gồm các tiêu đề đánh dấu rõ ràng các đối tượng là bộ nhớ cache hoặc không lưu trữ được. Nó cũng bao gồm các verbs – phần mà ra lệnh cho hành động mong muốn cho một cặp Yêu cầu HTTP - Phần này phá vỡ các nguyên tắc cơ bản của một số thuật ngữ lập trình, làm thế nào phù hợp với HTTP verbs và cách REST API sử dụng Uniform Resource Identifiers (URIs) để chỉ định dữ liệu mong muốntừ một lệnh gọi RESTful API.
CRUD và HTTP verb
Ngành công nghiệp phần mềm sử dụng từ viết tắt đáng nhớ CRUD cho bốn hành động chính được thực hiện bởi một ứng dụng. Những hành động đó là
Tạo: Cho phép khách hàng tạo một số mới trường hợp của các biến và cấu trúc dữ liệu tại máy chủ và khởi tạo các giá trị của chúng như được lưu giữ tại máy chủ
Đọc: Cho phép khách hàng truy xuất (đọc) hiện tại giá trị của các biến tồn tại ở máy chủ, lưu trữ một bản sao của các biến, cấu trúc và giá trị tại khách hàng
Cập nhật: Cho phép khách hàng thay đổi (cập nhật) giá trị của các biến tồn tại ở máy chủ
Xóa: Cho phép khách hàng xóa khỏi máy chủ các trường hợp khác nhau của các biến dữ liệu
Khái niệm tạo cấu hình mới tại bộ điều khiển được thực hiện thông qua API bằng cách tạo hành động theo từ viết tắt chung CRUD.
Các ví dụ khác về các hành động CRUD bao gồm kiểm tra trạng thái của cấu hình mới đó (một hành động đọc), một cập nhật để thay đổi một số cài đặt cụ thể trong mới cấu hình (một hành động cập nhật) hoặc một hành động để loại bỏ định nghĩa chính sách bảo mật hoàn toàn (xóa hoạt động).
HTTP sử dụng các verbs phản ánh hành động CRUD. Các thông điệp HTTP cũng bao gồm một URI, xác định tài nguyên cho yêu cầu này. Như mọi khi, thông điệp HTTP được mang theo trong IP và TCP, với các tiêu đề và dữ liệu, như được trình bày trong hình 18-4.
Hình 18-4 Động từ HTTP và URI trong HTTP tiêu đề yêu cầu
Bất cứ khi nào bạn mở trình duyệt web và nhấp vào một liên kết, trình duyệt của bạn tạo yêu cầu HTTP GET. Các thông báo bao gồm một HTTP header với động từ GET và URI. Các tài nguyên được trả về là các thành phần của một trang web, như văn bản, hình ảnh, video.
HTTP hoạt động tốt với REST một phần vì HTTP có động từ phù hợp với các hành động CRUD.
Sử dụng URI với HTTP để chỉ định tài nguyên
Ngoài việc sử dụng các HTTP verb để thực hiện CRUD, REST sử dụng các URI để xác định yêu cầu HTTP hoạt động trên tài nguyên nào. Đối với REST API, tài nguyên có thể là một trong nhiều tài nguyên được xác định bởi API. Mỗi tài nguyên chứa một tập hợp các biến liên quan, được xác định bởi API và được xác định bởi một URI. Chẳng hạn, hãy tưởng tượng người dùng tạo API dựa trên REST. Khi họ làm như vậy, người dùng tạo ra một bộ tài nguyên cô ấy muốn cung cấp thông qua API và cô ấy cũng gán một URI duy nhất cho mỗi tài nguyên. Nói cách khác, người tạo API sẽ tạo ra URI và một bộ phù hợp các biến và định nghĩa các hành động có thể được thực hiện chống lại các biến đó (đọc, cập nhật, v.v.).
Trình tạo API cũng tạo tài liệu API liệt kê các tài nguyên và URI xác định từng tài nguyên tài nguyên. Lập trình viên cho một ứng dụng dùng REST client có thể đọc các tài liệu về API, xây dựng một yêu cầu REST API và yêu cầu tài nguyên cụ thể, như ví dụ trong hình 18-5.
Hình 18-5 Một URI cho mỗi tài nguyên API Cái nhìn khái niệm
Hình 18-5 cho thấy các URI là các giá trị chung; Tuy nhiên, ngày nay các kỹ sư mạng cần có khả năng đọc tài liệu về API, xem URI trong tài liệu đó và hiểu ý nghĩa của từng phần của URI. Hình 18-6 hiển thị một URI cụ thể cho controller DNA của Cisco.
Hình 18-6 Cấu trúc URI cho yêu cầu REST GET
Hình vẽ cho thấy các giá trị và khái niệm quan trọng:
HTTPS: các chữ cái trước: // xác định giao thức được sử dụng trong trường hợp này, HTTP Secure (sử dụng HTTP với mã hóa SSL).
Tên máy chủ hoặc địa chỉ IP: Giá trị này nằm giữa // và đầu tiên /, giúp xác định máy chủ; nếu sử dụng một tên máy chủ, REST client phải thực hiện việc phân giải tên để tìm hiểu địa chỉ IP của máy chủ REST.
Đường dẫn (Tài nguyên): Giá trị này nằm sau giá trị đầu tiên / và kết thúc hoặc ở cuối URI hoặc trước đó bất kỳ trường bổ sung nào (như truy vấn tham số). HTTP gọi trường này là đường dẫn, nhưng để sử dụng với REST, trường xác định duy nhất tài nguyên như được xác định bởi API.
Hình 18-7 Trang tài liệu API của Trung tâm DNA cho Tài nguyên thiết bị mạng (Danh sách)
REST API sử dụng các trường trong HTTP header để mã hóa phần lớn thông tin xác thực cho các cuộc gọi REST. Chẳng hạn, URI trong hình 18-6 hỏi DNA danh sách tất cả các thiết bị đã biết. Cisco DNA sẽ trả về một từ điển các giá trị cho mỗi thiết bị. Thay vào đó, bạn có thể muốn từ điển giá trị đó cho chỉ một thiết bị duy nhất.
Hình 18-8 tóm tắt các thành phần chính của Các URI thường được sử dụng với REST API, với phần tài nguyên và tham số của việc xác định URI cụ thể những gì API sẽ cung cấp cho REST client.
Hình 18-8 Các thành phần ví dụ của một URI được sử dụng trong một lệnh gọi REST API
Ví dụ về lệnh gọi REST API tới DNA Center
Để kết hợp một số khái niệm REST API với nhau, chúng ta khảo sát hoạt động thông qua một vài lệnh gọi API mẫu.
Đối với quan điểm của developer, khi làm việc để tự động hóa một số nhiệm vụ vận hành mạng, bạn sẽ sử dụng một chương trình tạo các lời gọi API. Tuy nhiên, trong quá trình phát triển ứng dụng, trước tiên bạn có thể tập trung vào dữ liệu có sẵn từ API và bỏ qua tất cả các chi tiết lập trình đầu tiên. Môi trường phát triển API cho phép bạn tập trung vào các lệnh gọi API. Sau đó, cùng một công cụ có thể tạo ra mã chính xác mà bạn có thể sao chép vào chương trình của bạn để thực hiện các cuộc gọi API.
Các ví dụ trong phần này sử dụng một chương trình miễn phí có tên là Postman (www.postman.com). Lưu ý Cisco DevNet sử dụng Postman rất nhiều trong nhiều bài labs là ví dụ mẫu. Ví dụ đầu tiên cho thấy một ảnh chụp màn hình của một phần của ứng dụng sau khi nó gửi yêu cầu REST client GET tới REST API của Trung tâm DNA.
Hình 18-9 Cấu trúc URI cho yêu cầu REST GET
Hãy xem qua dữ liệu ở phía dưới của cửa sổ Postman trong hình 18-9. Văn bản sau một định dạng chuẩn mô hình hóa dữ liệu được gọi là JavaScript Object Notation (JSON). Để giúp bạn xem văn bản, Ví dụ 18-3 hiển thị một số kết quả ở dạng JSON.
Ví dụ 18-3 Đầu ra JSON từ lệnh gọi REST API
Các công cụ phát triển API như Postman giúp bạn giải quyết các chi tiết của từng lệnh gọi API, lưu các chi tiết và chia sẻ với các kỹ sư và nhà phát triển khác. Cuối cùng, bạn sẽ sẵn sàng thực hiện cuộc gọi API từ một chương trình. Với một cú nhấp chuột đơn giản từ UI Postman, Postman cung cấp mã để sao chép / dán vào chương trình của bạn.
Bây giờ, bạn có một kiến thức nền tảng tốt về cơ chế của REST API. Bằng cách học thêm một số kỹ năng, và sử dụng tài liệu API cho bất kỳ REST API nào, bạn có thể thử nghiệm và thử tạo các cuộc gọi REST API.
API tồn tại để cho phép hai chương trình trao đổi dữ liệu. Một số API có thể được thiết kế như một giao thức giữa các chương trình chạy trên cùng một máy tính, vì vậy giao tiếp giữa các chương trình xảy ra trong một hệ điều hành đơn. Nhiều API cần phải có sẵn đến các chương trình chạy trên các máy tính khác, vì vậy API phải xác định loại giao thức mạng được hỗ trợ bởi API và nhiều API dựa trên REST sử dụng HTTP.
Những người tạo REST API thường chọn HTTP bởi vì HTTP phù hợp với một số khái niệm được định nghĩa chung cho REST API. HTTP sử dụng nguyên tắc tương tự như REST: nó hoạt động với mô hình máy khách / máy chủ; nó sử dụng một mô hình hoạt động phi trạng thái; và nó bao gồm các tiêu đề đánh dấu rõ ràng các đối tượng là bộ nhớ cache hoặc không lưu trữ được. Nó cũng bao gồm các verbs – phần mà ra lệnh cho hành động mong muốn cho một cặp Yêu cầu HTTP - Phần này phá vỡ các nguyên tắc cơ bản của một số thuật ngữ lập trình, làm thế nào phù hợp với HTTP verbs và cách REST API sử dụng Uniform Resource Identifiers (URIs) để chỉ định dữ liệu mong muốntừ một lệnh gọi RESTful API.
CRUD và HTTP verb
Ngành công nghiệp phần mềm sử dụng từ viết tắt đáng nhớ CRUD cho bốn hành động chính được thực hiện bởi một ứng dụng. Những hành động đó là
Tạo: Cho phép khách hàng tạo một số mới trường hợp của các biến và cấu trúc dữ liệu tại máy chủ và khởi tạo các giá trị của chúng như được lưu giữ tại máy chủ
Đọc: Cho phép khách hàng truy xuất (đọc) hiện tại giá trị của các biến tồn tại ở máy chủ, lưu trữ một bản sao của các biến, cấu trúc và giá trị tại khách hàng
Cập nhật: Cho phép khách hàng thay đổi (cập nhật) giá trị của các biến tồn tại ở máy chủ
Xóa: Cho phép khách hàng xóa khỏi máy chủ các trường hợp khác nhau của các biến dữ liệu
Khái niệm tạo cấu hình mới tại bộ điều khiển được thực hiện thông qua API bằng cách tạo hành động theo từ viết tắt chung CRUD.
Các ví dụ khác về các hành động CRUD bao gồm kiểm tra trạng thái của cấu hình mới đó (một hành động đọc), một cập nhật để thay đổi một số cài đặt cụ thể trong mới cấu hình (một hành động cập nhật) hoặc một hành động để loại bỏ định nghĩa chính sách bảo mật hoàn toàn (xóa hoạt động).
HTTP sử dụng các verbs phản ánh hành động CRUD. Các thông điệp HTTP cũng bao gồm một URI, xác định tài nguyên cho yêu cầu này. Như mọi khi, thông điệp HTTP được mang theo trong IP và TCP, với các tiêu đề và dữ liệu, như được trình bày trong hình 18-4.
Hình 18-4 Động từ HTTP và URI trong HTTP tiêu đề yêu cầu
Bất cứ khi nào bạn mở trình duyệt web và nhấp vào một liên kết, trình duyệt của bạn tạo yêu cầu HTTP GET. Các thông báo bao gồm một HTTP header với động từ GET và URI. Các tài nguyên được trả về là các thành phần của một trang web, như văn bản, hình ảnh, video.
HTTP hoạt động tốt với REST một phần vì HTTP có động từ phù hợp với các hành động CRUD.
Sử dụng URI với HTTP để chỉ định tài nguyên
Ngoài việc sử dụng các HTTP verb để thực hiện CRUD, REST sử dụng các URI để xác định yêu cầu HTTP hoạt động trên tài nguyên nào. Đối với REST API, tài nguyên có thể là một trong nhiều tài nguyên được xác định bởi API. Mỗi tài nguyên chứa một tập hợp các biến liên quan, được xác định bởi API và được xác định bởi một URI. Chẳng hạn, hãy tưởng tượng người dùng tạo API dựa trên REST. Khi họ làm như vậy, người dùng tạo ra một bộ tài nguyên cô ấy muốn cung cấp thông qua API và cô ấy cũng gán một URI duy nhất cho mỗi tài nguyên. Nói cách khác, người tạo API sẽ tạo ra URI và một bộ phù hợp các biến và định nghĩa các hành động có thể được thực hiện chống lại các biến đó (đọc, cập nhật, v.v.).
Trình tạo API cũng tạo tài liệu API liệt kê các tài nguyên và URI xác định từng tài nguyên tài nguyên. Lập trình viên cho một ứng dụng dùng REST client có thể đọc các tài liệu về API, xây dựng một yêu cầu REST API và yêu cầu tài nguyên cụ thể, như ví dụ trong hình 18-5.
Hình 18-5 Một URI cho mỗi tài nguyên API Cái nhìn khái niệm
Hình 18-5 cho thấy các URI là các giá trị chung; Tuy nhiên, ngày nay các kỹ sư mạng cần có khả năng đọc tài liệu về API, xem URI trong tài liệu đó và hiểu ý nghĩa của từng phần của URI. Hình 18-6 hiển thị một URI cụ thể cho controller DNA của Cisco.
Hình 18-6 Cấu trúc URI cho yêu cầu REST GET
Hình vẽ cho thấy các giá trị và khái niệm quan trọng:
HTTPS: các chữ cái trước: // xác định giao thức được sử dụng trong trường hợp này, HTTP Secure (sử dụng HTTP với mã hóa SSL).
Tên máy chủ hoặc địa chỉ IP: Giá trị này nằm giữa // và đầu tiên /, giúp xác định máy chủ; nếu sử dụng một tên máy chủ, REST client phải thực hiện việc phân giải tên để tìm hiểu địa chỉ IP của máy chủ REST.
Đường dẫn (Tài nguyên): Giá trị này nằm sau giá trị đầu tiên / và kết thúc hoặc ở cuối URI hoặc trước đó bất kỳ trường bổ sung nào (như truy vấn tham số). HTTP gọi trường này là đường dẫn, nhưng để sử dụng với REST, trường xác định duy nhất tài nguyên như được xác định bởi API.
Hình 18-7 Trang tài liệu API của Trung tâm DNA cho Tài nguyên thiết bị mạng (Danh sách)
REST API sử dụng các trường trong HTTP header để mã hóa phần lớn thông tin xác thực cho các cuộc gọi REST. Chẳng hạn, URI trong hình 18-6 hỏi DNA danh sách tất cả các thiết bị đã biết. Cisco DNA sẽ trả về một từ điển các giá trị cho mỗi thiết bị. Thay vào đó, bạn có thể muốn từ điển giá trị đó cho chỉ một thiết bị duy nhất.
Hình 18-8 tóm tắt các thành phần chính của Các URI thường được sử dụng với REST API, với phần tài nguyên và tham số của việc xác định URI cụ thể những gì API sẽ cung cấp cho REST client.
Hình 18-8 Các thành phần ví dụ của một URI được sử dụng trong một lệnh gọi REST API
Ví dụ về lệnh gọi REST API tới DNA Center
Để kết hợp một số khái niệm REST API với nhau, chúng ta khảo sát hoạt động thông qua một vài lệnh gọi API mẫu.
Đối với quan điểm của developer, khi làm việc để tự động hóa một số nhiệm vụ vận hành mạng, bạn sẽ sử dụng một chương trình tạo các lời gọi API. Tuy nhiên, trong quá trình phát triển ứng dụng, trước tiên bạn có thể tập trung vào dữ liệu có sẵn từ API và bỏ qua tất cả các chi tiết lập trình đầu tiên. Môi trường phát triển API cho phép bạn tập trung vào các lệnh gọi API. Sau đó, cùng một công cụ có thể tạo ra mã chính xác mà bạn có thể sao chép vào chương trình của bạn để thực hiện các cuộc gọi API.
Các ví dụ trong phần này sử dụng một chương trình miễn phí có tên là Postman (www.postman.com). Lưu ý Cisco DevNet sử dụng Postman rất nhiều trong nhiều bài labs là ví dụ mẫu. Ví dụ đầu tiên cho thấy một ảnh chụp màn hình của một phần của ứng dụng sau khi nó gửi yêu cầu REST client GET tới REST API của Trung tâm DNA.
- URI, gần đầu trang, liệt kê tên máy chủ của sandboxdnac2.cisco.com.
- Phần tài nguyên của URI hiển thị cùng một tài nguyên được liệt kê trước đó trong hình 18-6, yêu cầu danh sách các thiết bị.
- Trung tâm dưới cùng của cửa sổ hiển thị dữ liệu được trả về bởi DNAC, phản hồi REST HTTP GET.
Hình 18-9 Cấu trúc URI cho yêu cầu REST GET
Hãy xem qua dữ liệu ở phía dưới của cửa sổ Postman trong hình 18-9. Văn bản sau một định dạng chuẩn mô hình hóa dữ liệu được gọi là JavaScript Object Notation (JSON). Để giúp bạn xem văn bản, Ví dụ 18-3 hiển thị một số kết quả ở dạng JSON.
Ví dụ 18-3 Đầu ra JSON từ lệnh gọi REST API
Các công cụ phát triển API như Postman giúp bạn giải quyết các chi tiết của từng lệnh gọi API, lưu các chi tiết và chia sẻ với các kỹ sư và nhà phát triển khác. Cuối cùng, bạn sẽ sẵn sàng thực hiện cuộc gọi API từ một chương trình. Với một cú nhấp chuột đơn giản từ UI Postman, Postman cung cấp mã để sao chép / dán vào chương trình của bạn.
Bây giờ, bạn có một kiến thức nền tảng tốt về cơ chế của REST API. Bằng cách học thêm một số kỹ năng, và sử dụng tài liệu API cho bất kỳ REST API nào, bạn có thể thử nghiệm và thử tạo các cuộc gọi REST API.