REST-BASED APIS
Trong thế giới của các API, một số ứng dụng tạo ra API, một số ứng dụng khác sử dụng (tiêu thụ) API. Khi viết một ứng dụng, nhà phát triển sẽ viết một số mã nguồn (source code), nhưng thường thì nhà phát triển có thể làm rất nhiều việc bằng cách tìm kiếm và sử dụng các API. Kết quả là, phần lớn các phần mềm hiện đại sử dụng API cùng với các thư viện có sẵn.
REST-Based (RESTful) APIs
REST API tuân theo một bộ quy tắc nền tảng của kiến trúc REST. Đầu tiên, theo nghĩa đen, REST API bao gồm sáu thuộc tính được định nghĩa. Sáu thuộc tính đó là
Ba thuộc tính đầu tiên là cốt lõi của REST API.
Kiến trúc máy khách / máy chủ
Giống như nhiều ứng dụng, REST sử dụng một mô hình kiến trúc máy khách / máy chủ. Đầu tiên, một ứng dụng nhà phát triển tạo REST API và ứng dụng đó, khi thực thi, hoạt động như một máy chủ REST. Bất kỳ khác ứng dụng có thể thực hiện cuộc gọi REST API bằng cách thực thi một số mã gây ra yêu cầu từ máy khách đến máy chủ. Ví dụ, trong Hình 18-1
1. Máy khách REST ở bên trái thực hiện lệnh gọi REST API, tạo ra một thông điệp được gửi đến máy chủ REST.
2. Máy chủ REST ở bên phải có mã API xem xét yêu cầu và quyết định cách trả lời.
3. Máy chủ REST gửi lại thông điệp trả lời phù hợp với biến dữ liệu.
Hình 18-1 Hoạt động của Máy khách / Máy chủ với REST
Hoạt động phi trạng thái (stateless)
Thuộc tính phi trạng thái của REST API có nghĩa là REST không ghi lại và sử dụng thông tin về một API trao đổi cho API tiếp theo. Nói cách khác, mỗi API yêu cầu và trả lời không sử dụng bất kỳ lịch sử quá khứ nào khác xem xét khi xử lý yêu cầu.
Để so sánh, giao thức TCP sử dụng stateful, trong khi UDP sử dụng hoạt động stateless.
Có thể lưu cache (hoặc không)
Để đánh giá ý nghĩa của bộ nhớ cache, hãy xem xét những gì xảy ra khi bạn duyệt một trang web. Khi bạn trình duyệt tải một trang web mới, bản thân trang chứa một nhiều đối tượng (văn bản, hình ảnh, video, âm thanh). Một số đối tượng hiếm khi thay đổi, vì vậy sẽ tốt hơn để tải đối tượng một lần và không tải lại; trong trong trường hợp đó, máy chủ đánh dấu đối tượng đó là bộ nhớ cache. Ví dụ, logo hoặc hình ảnh khác được hiển thị trên nhiều trang của một trang web sẽ gần như không bao giờ thay đổi và có khả năng được lưu trữ. Tuy nhiên, danh sách sản phẩm được trả lại trong của bạn tìm kiếm gần đây nhất của trang web sẽ không được có thể lưu trong bộ nhớ cache vì máy chủ muốn cập nhật và cung cấp một danh sách mới mỗi khi bạn yêu cầu trang.
REST API yêu cầu mọi tài nguyên được yêu cầu thông qua một lời gọi API có một phương thức rõ ràng để đánh dấu tài nguyên như bộ nhớ cache hay không. Các mục tiêu vẫn là tương tự: cải thiện hiệu suất bằng cách lấy tài nguyên ít hơn thường (lưu trữ). Lưu ý rằng tài nguyên có thể lưu trong bộ nhớ cache là được đánh dấu bằng khung thời gian để khách hàng biết khi nào để yêu cầu một bản sao mới của tài nguyên một lần nữa.
Biến đơn giản
Trong lập trình, một biến là một tên hoặc nhãn có một giá trị được gán. Để có được hiểu biết chung cho biến lập trình, bạn có thể nghĩ về biến như các biến từ phương trình đại số.Ví dụ 18-1 cho thấy một số mẫu biến các loại khác nhau trong một chương trình Python (Python ngôn ngữ là ngôn ngữ phổ biến nhất hiện nay để viết ứng dụng tự động hóa mạng). Chương trình này bắt đầu với một nhận xét (ba dòng trên cùng với ba đơn dấu ngoặc kép) và sau đó tạo bốn biến, gán chúng đến các giá trị khác nhau và in một dòng đầu ra: sản phẩm là -12.
Ví dụ 18-1 Chương trình Python đơn giản cho thấy một Sản phẩm
Các biến trong ví dụ 18-1 có thể được gọi là đơn giản biến vì mỗi tên biến có một giá trị duy nhất Liên kết với nó. Biến đơn giản có một biến Tên và một giá trị liên quan, vì vậy chúng có một đơn giản kết cấu. Các loại giá trị của chúng tôi có thể có nhiều như là một trong những ví dụ 18-1. Ví dụ bao gồm các phần mềm
Số nguyên không dấu (x)
Số nguyên đã ký (y)
Số dấu phẩy động (z)
Văn bản (tiêu đề)
Danh sách và từ điển biến
Trong khi các biến đơn giản có nhiều công dụng tuyệt vời, các chương trình cần có cấu trúc dữ liệu phức tạp hơn. Trong lập trình, cấu trúc dữ liệu xác định một tập hợp liên quan các biến và giá trị. Chẳng hạn, Python sử dụng danh sách các biến để một tên biến được gán một giá trị đó là một danh sách các giá trị chứ không phải là một giá trị. Bạn có thể tưởng tượng rằng một chương trình tự động hóa mạng có thể muốn có danh sách, chẳng hạn như danh sách các thiết bị được quản lý, danh sách các giao diện trên thiết bị hoặc danh sách cài đặt cấu hình trên một giao diện. Đầu tiên, hãy xem xét biến có tên list1 trong Ví dụ 18-2; lưu ý rằng các dòng bắt đầu bằng # là nhận xét.
Ví dụ 18-2 Danh sách mẫu và biến từ điển trong Python
Ngay cả khi bạn chưa bao giờ thấy mã Python trước đây, bạn có thể đoán một số ý nghĩa của biến list1. Các mã gán biến list1 cho một giá trị mà chính nó là danh sách ba chuỗi văn bản. Lưu ý rằng danh sách có thể bao gồm văn bản, số nguyên không dấu, số nguyên đã ký, v.v.
Hình 18-2 cho thấy cấu trúc dữ liệu đằng sau biến
list1 trong ví dụ 18-2. Biến được gán cho danh sách,
với danh sách có ba yếu tố danh sách.
Hình 18-2 Cấu trúc dữ liệu danh sách trong Python
Python hỗ trợ một cấu trúc dữ liệu tương tự được gọi là từ điển. Nếu bạn nghĩ về nội dung của một từ điển đối với ngôn ngữ tiếng Anh, từ điển đó liệt kê một loạt các mục được ghép nối: một thuật ngữ và định nghĩa phù hợp. Với ngôn ngữ lập trình như Python, dữ liệu từ điển cấu trúc cũng liệt kê các mục được ghép nối: các khóa (như thuật ngữ) và các giá trị (như định nghĩa). Hình 18-3 cho thấy cấu trúc của giá trị từ điển đó khớp với dict1 biến ở cuối ví dụ. Lưu ý rằng mỗi khóa và giá trị của nó được gọi là cặp khóa: giá trị.
Hình 18-3 Cấu trúc dữ liệu từ điển trong Python
Cấu trúc dữ liệu có thể trở nên phức tạp hơn. Ngoài ra, cấu trúc dữ liệu có thể được lồng nhau. Chẳng hạn, một giá trị biến đổi có thể là một danh sách, với mỗi phần tử danh sách là một từ điển, với các giá trị trong một số khóa: value cặp là danh sách khác, và như vậy. Ngay bây giờ, hãy chú ý đến thực tế là các chương trình sử dụng các biến đơn giản nhưng cũng sử dụng liệt kê các biến và từ điển để dễ thực hiện hơn các loại logic khác nhau
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.
Ở giữa bên phải, nó liệt kê mã trạng thái GET phản hồi GET là 200, có nghĩa là OK.
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 bây giờ có thể thử nghiệm và thử tạo các cuộc gọi REST API.
