CHÀO! Hôm nay chúng ta sẽ tìm hiểu về một chủ đề rất thú vị và quan trọng nhất là có nhu cầu cao trên thị trường lao động: REST. Chúng tôi sẽ chia tổng quan về REST thành ba phần:
Trong phần đầu tiên, chúng tôi sẽ đề cập đến lịch sử của REST và mô tả các nguyên tắc mà REST dựa trên đó.
Trong phần thứ hai, chúng ta sẽ xem xét cách giao tiếp giữa máy khách và máy chủ diễn ra thông qua giao thức HTTP.
Trong phần ba, chúng tôi sẽ viết một ứng dụng RESTful nhỏ mà chúng tôi sẽ kiểm tra bằng chương trình có tên "Người đưa thư".
Bài viết dành cho độc giả quen thuộc với các thuật ngữ sau:
HTTP
URL và URI
JSON và (ở mức độ thấp hơn) XML
tiêm phụ thuộc
Phần 1. REST là gì?
REST, giống như rất nhiều thứ trong thế giới CNTT, là một từ viết tắt. Nó có nguồn gốc từ "Chuyển giao trạng thái đại diện" . Đây là một kiểu kiến trúc cho sự tương tác giữa các thành phần của hệ thống phân tán trong mạng máy tính. Nói một cách đơn giản, REST xác định kiểu tương tác (trao đổi dữ liệu) giữa các thành phần khác nhau của hệ thống, mỗi thành phần có thể được đặt ở những vị trí khác nhau. Phong cách kiến trúc này là một tập nhất quán các ràng buộc tuân theo khi thiết kế một hệ thống phân tán. Những ràng buộc này đôi khi được gọi là nguyên tắc hướng dẫn của REST. Không có nhiều, chỉ có 6. Chúng ta sẽ nói về chúng sau.
Các ứng dụng được xây dựng với các nguyên tắc REST, tức là những ứng dụng không vi phạm các ràng buộc của REST, được gọi là "RESTful".
Lịch sử của REST
Thuật ngữ REST được giới thiệu bởi Roy Fielding, một trong những người tạo ra giao thức HTTP, trong luận án tiến sĩ của ông. luận án có tựa đề "Phong cách kiến trúc và thiết kế kiến trúc phần mềm dựa trên mạng" vào năm 2000. Mặc dù thuật ngữ REST vẫn có thể được gọi là non trẻ, nhưng khái niệm mà nó đại diện nằm ở cốt lõi của World Wide Web. Chúng tôi sẽ không đi sâu vào lịch sử của thuật ngữ này. Nếu bạn muốn đi sâu vào các nguồn chính, hãy xem luận văn của Fielding .
Các ràng buộc và nguyên tắc REST
Như đã nêu ở trên, REST xác định cách các thành phần của hệ thống phân tán tương tác với nhau. Nói chung, điều này xảy ra thông qua một quá trình yêu cầu-phản hồi. Thành phần gửi yêu cầu được gọi là máy khách và thành phần xử lý yêu cầu và gửi phản hồi cho máy khách được gọi là máy chủ. Yêu cầu và phản hồi thường được gửi qua giao thức HTTP. HTTP là viết tắt của Giao thức truyền siêu văn bản. Thông thường, một máy chủ là một số ứng dụng web. Khách hàng có thể là hầu hết mọi thứ. Ví dụ: ứng dụng dành cho thiết bị di động yêu cầu dữ liệu từ máy chủ. Hoặc một trình duyệt gửi yêu cầu từ một trang web đến máy chủ để tải xuống dữ liệu. Ứng dụng A có thể yêu cầu dữ liệu từ Ứng dụng B. Trong trường hợp này, A là máy khách đối với B và B là máy chủ đối với A. Đồng thời, A có thể xử lý các yêu cầu từ B, C, D, v.v. Trong trường hợp này, ứng dụng A vừa là máy chủ vừa là máy khách. Tất cả mọi thứ phụ thuộc vào bối cảnh. Một điều chắc chắn: thành phần gửi yêu cầu là máy khách. Thành phần tiếp nhận, xử lý và phản hồi yêu cầu là máy chủ. Tuy nhiên, không phải mọi hệ thống có các thành phần giao tiếp thông qua quy trình phản hồi yêu cầu đều là hệ thống RESTful. Để một hệ thống được coi là RESTful, nó phải tuân thủ sáu ràng buộc REST:
1. Kiến trúc máy khách-máy chủ
Hạn chế này là về sự tách biệt của các mối quan tâm. Cần phải tách các yêu cầu của giao diện máy khách khỏi các yêu cầu của máy chủ lưu trữ dữ liệu. Ràng buộc này làm cho mã máy khách dễ di chuyển hơn đến các nền tảng khác và việc đơn giản hóa phía máy chủ sẽ cải thiện khả năng mở rộng của hệ thống. Tạo sự khác biệt giữa "máy khách" và "máy chủ" cho phép chúng được phát triển độc lập với nhau.
2. Không quốc tịch
Kiến trúc RESTful yêu cầu đáp ứng các điều kiện sau. Trong khoảng thời gian giữa các yêu cầu, máy chủ không được lưu trữ thông tin về trạng thái của máy khách và ngược lại. Tất cả các yêu cầu từ máy khách phải được soạn theo cách cung cấp cho máy chủ tất cả thông tin cần thiết để hoàn thành yêu cầu. Do đó, cả máy chủ và máy khách đều có thể "hiểu" bất kỳ tin nhắn nào đã nhận mà không cần dựa vào các tin nhắn trước đó.
3. Có thể lưu vào bộ nhớ cache
Khách hàng có thể lưu trữ phản hồi của máy chủ. Đến lượt chúng, chúng phải được chỉ định rõ ràng hoặc ngầm định là được lưu trong bộ nhớ cache hoặc không được lưu trong bộ nhớ cache, để khách hàng không nhận được dữ liệu lỗi thời hoặc không chính xác khi đáp ứng các yêu cầu tiếp theo. Bộ nhớ đệm chính xác giúp loại bỏ hoàn toàn hoặc một phần một số tương tác máy khách-máy chủ, tăng thêm hiệu năng và khả năng mở rộng của hệ thống.
4. Giao diện thống nhất
Các yêu cầu cơ bản của kiến trúc RESTful bao gồm một giao diện thống nhất, thống nhất. Máy khách phải luôn hiểu định dạng và địa chỉ mà nó cần sử dụng khi gửi yêu cầu và ngược lại, máy chủ cũng phải hiểu định dạng mà nó sẽ sử dụng khi đáp ứng các yêu cầu của máy khách. Tương tác máy khách-máy chủ nhất quán này mô tả cái gì, ở đâu, ở dạng nào và cách gửi dữ liệu là một giao diện thống nhất.
5. Lớp
Theo các lớp, chúng tôi muốn nói đến cấu trúc phân cấp của mạng. Đôi khi một máy khách có thể giao tiếp trực tiếp với máy chủ và đôi khi nó chỉ giao tiếp với một nút trung gian. Việc sử dụng máy chủ trung gian có thể tăng khả năng mở rộng nhờ cân bằng tải và bộ nhớ đệm phân tán. Hãy cung cấp một ví dụ. Hãy tưởng tượng một ứng dụng di động phổ biến trên toàn thế giới. Một phần không thể thiếu của ứng dụng liên quan đến tải hình ảnh. Người dùng của nó lên tới hàng triệu người, vì vậy một máy chủ đơn lẻ không thể xử lý tải nặng như vậy. Việc tách hệ thống thành các lớp sẽ giải quyết vấn đề này. Nếu máy khách yêu cầu ảnh từ một nút trung gian, thì nút trung gian sẽ yêu cầu ảnh từ máy chủ được tải ít nhất vào lúc này và trả lại ảnh cho máy khách. Nếu bộ nhớ đệm được áp dụng chính xác ở mỗi cấp của hệ thống phân cấp,
6. Mã theo yêu cầu (không bắt buộc)
Ràng buộc này ngụ ý rằng máy khách có thể mở rộng chức năng của nó bằng cách tải xuống mã từ máy chủ dưới dạng applet hoặc tập lệnh.
Ưu điểm của kiến trúc RESTful
Các ứng dụng tuân thủ tất cả các ràng buộc nói trên có những ưu điểm sau: độ tin cậy (không cần lưu trạng thái của máy khách, trạng thái này có thể bị mất)
hiệu suất (do sử dụng bộ đệm)
khả năng mở rộng
giao tiếp minh bạch
giao diện đơn giản
tính di động
khả năng thực hiện thay đổi dễ dàng
khả năng phát triển và thích ứng với các yêu cầu mới
Chúng tôi sẽ chia tổng quan về REST thành ba phần:
