Xin chào, hôm nay chúng ta sẽ nghiên cứu một chủ đề rất thú vị và quan trọng nhất là đang có nhu cầu 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 ta sẽ đề cập đến lịch sử của REST và mô tả các nguyên tắc làm nền tảng cho REST.
Trong phần thứ hai, chúng ta sẽ xem cách giao tiếp diễn ra giữa máy khách và máy chủ thông qua giao thức HTTP.
Trong phần thứ 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 Postman.
Bài viết dành cho người đọc quen thuộc với các thuật ngữ sau:
HTTP;
URL và URI;
JSON và ở mức độ thấp hơn là XML;
Tiêm phụ thuộc.
Phần 1. REST là gì
REST, giống như nhiều thứ trong thế giới CNTT, là từ viết tắt của Chuyển giao trạng thái đại diện . Đây là một kiểu kiến trúc 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 ở các vị trí khác nhau. Phong cách kiến trúc này thể hiện một tập hợp các ràng buộc nhất quán được xem xét khi thiết kế một hệ thống phân tán. Những hạn chế này đôi khi được gọi là nguyên tắc REST. Không có nhiều trong số chúng, chỉ có 6 miếng. Chúng ta sẽ nói về họ một lát sau.
Các ứng dụng được xây dựng dựa trên REST, tức là không vi phạm các hạn chế do REST áp đặt được gọi là RESTful.
Lịch sử của REST
Thuật ngữ REST được đặt ra 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ĩ "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. Có thể nói rằng thuật ngữ REST vẫn còn non trẻ, mặc dù khái niệm của nó nằm ở nền tảng của World Wide Web. Chúng tôi sẽ không đi sâu vào lịch sử nguồn gốc của thuật ngữ này. Nếu bạn muốn đi sâu vào các nguồn gốc, hãy xem luận án của Fielding .
Các hạn chế 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 sẽ tương tác với nhau. Nói chung, điều này xảy ra thông qua phản hồi yêu cầu. Thành phần gửi yêu cầu được gọi là client ; Thành phần xử lý yêu cầu và gửi phản hồi đến 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 HTTP (Giao thức truyền siêu văn bản). Thông thường, máy chủ là một loại ứng dụng web. Khách hàng có thể không chỉ là bất cứ thứ gì, mà còn có thể là rất nhiều. Ví dụ: một ứng dụng di động yêu cầu dữ liệu từ máy chủ. Hoặc trình duyệt gửi yêu cầu từ trang web đến máy chủ để tải dữ liệu. Ứng dụng A có thể yêu cầu dữ liệu từ ứng dụng B. Khi đó A là máy khách liên quan đến B và B là máy chủ liên quan đến A. Đồng thời, A có thể xử lý các yêu cầu từ C, D, 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ả phụ thuộc vào bối cảnh. Một điều rõ ràng: 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 qua phản hồi yêu cầu đều là hệ thống REST (hoặc RESTful). Để một hệ thống được coi là RESTful, nó phải “phù hợp” với sáu ràng buộc REST:
1. Đưa kiến trúc vào mô hình client-server
Cơ sở của hạn chế này là sự khác biệt về nhu cầu. Cần tách biệt nhu cầu của giao diện máy khách với nhu cầu của máy chủ lưu trữ dữ liệu. Hạn chế này làm tăng khả năng di chuyển của mã máy khách sang các nền tảng khác và việc đơn giản hóa phần máy chủ sẽ cải thiện khả năng mở rộng của hệ thống. Sự khác biệt giữa “máy khách” và “máy chủ” cho phép chúng phát triển độc lập với nhau.
2. Thiếu điều kiện
Kiến trúc REST yêu cầu phải đáp ứng điều kiện sau. Giữa các yêu cầu, máy chủ không cần 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 cấu trúc sao cho máy chủ nhận được tất cả thông tin cần thiết để hoàn thành yêu cầu. Bằng cách này, cả máy chủ và máy khách đều có thể “hiểu” bất kỳ tin nhắn nào nhận được mà không cần dựa vào các tin nhắn trước đó.
3. Bộ nhớ đệm
Khách hàng có thể lưu trữ phản hồi của máy chủ. Ngược lại, những dữ liệu này phải được chỉ định rõ ràng hoặc ngầm định là có thể lưu vào bộ nhớ đệm hoặc không thể lưu vào bộ nhớ đệm, để khách hàng không nhận được dữ liệu cũ hoặc không chính xác để đáp ứng các yêu cầu tiếp theo. Việc sử dụng bộ nhớ đệm đúng cách sẽ giúp loại bỏ hoàn toàn hoặc một phần một số tương tác giữa máy khách và máy chủ, giúp tăng thêm hiệu suất và khả năng mở rộng của hệ thống.
4. Tính đồng nhất của giao diện
Các yêu cầu cơ bản của kiến trúc REST bao gồm một giao diện thống nhất, nhất quán. Máy khách phải luôn hiểu định dạng và địa chỉ nào nó cần để gửi yêu cầu và đến lượt máy chủ cũng phải hiểu định dạng nào sẽ đáp ứng yêu cầu của máy khách. Đây là một định dạng thống nhất cho sự tương tác giữa máy khách và máy chủ, mô tả cái gì, ở đâu, dưới hình thức nào và cách gửi và là một giao diện hợp nhất
5. Lớp
Các lớp đề cập đến cấu trúc phân cấp của mạng. Đôi khi máy khách có thể giao tiếp trực tiếp với máy chủ và đôi khi nó có thể giao tiếp đơn giản 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 thông qua cân bằng tải và bộ nhớ đệm phân tán. Hãy đưa ra 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. Phần không thể thiếu của nó là tải hình ảnh. Vì có hàng triệu người dùng nên một máy chủ không thể chịu được tải nặng như vậy. Việc chia hệ thống thành các lớp sẽ giải quyết được vấn đề này. Máy khách sẽ yêu cầu một hình ảnh từ nút trung gian, nút trung gian sẽ yêu cầu hình ảnh từ máy chủ được tải ít nhất vào lúc này và sẽ trả lại hình ảnh cho máy khách. Nếu bộ nhớ đệm được áp dụng chính xác ở đây ở mỗi cấp độ phân cấp thì có thể đạt được khả năng mở rộng hệ thống tốt.
6. Code theo yêu cầu (hạn chế tùy chọn)
Hạn chế này ngụ ý rằng máy khách có thể mở rộng chức năng của mình bằng cách tải xuống mã từ máy chủ dưới dạng applet hoặc tập lệnh.
Lợi ích của REST
Các ứng dụng tuân thủ tất cả các hạn chế trên có những ưu điểm sau: độ tin cậy (không cần lưu trữ thông tin trạng thái máy khách, thông tin này có thể bị mất);
GO TO FULL VERSION