REST là gì?

REST là gì?

 

Nội dung bài viết:

1. REST là gì?

2. Những ràng buộc chung của REST

3. Phần tử REST

4. RESTful thực hiện

5. REST và HTTP

6. RESTful APIs

 

1. REST là gì?

- REST là một định nghĩa kiểu kiến trúc (Architecture Style) được áp dụng cho các ứng dụng được nối mạng (Networked Applications). Nó tồn tại như một loạt các ràng buộc (Constraints) được áp dụng cho việc triển khai các thành phần mạng, cho phép ngữ nghĩa giao diện thống nhất, thay vì các triển khai và cú pháp dành riêng cho ứng dụng.

 

- REST là một kiến trúc mạng lần đầu tiên được ghi lại bởi Roy Fielding trong luận án tiến sĩ của ông có tiêu đề “Architectural Styles and the Design of Network-based Software Architectures”, được xuất bản vào năm 2000. REST cho phép máy khách (Clients) tương tác với dữ liệu được lưu trữ trên máy chủ (Servers) mà không cần phải có bất kỳ kiến thức trước nào về máy chủ hoặc những gì tồn tại trên đó.

 

 

REST là viết tắt của gì?

REST là viết tắt của từ “Representational State Transfer”, trong tiếng Việt có nghĩa là “Chuyển trạng thái trình bày”. Những người theo chủ nghĩa thuần túy viết tắt thường viết nó là ReST, vì chữ E trong REST không thực sự đại diện cho bất cứ điều gì. Nó chỉ là chữ cái thứ hai của từ “Representational”. Điều này tránh những tranh cãi về cách phát âm nó, giống như vấn đề đã gây khó khăn cho GIF trong những năm gần đây. Với chữ E bao gồm, không có sự nhầm lẫn khi phát âm từ viết tắt chính xác hơn của RST là cổ tay “wrist” hoặc thậm chí là R-S-T.

 

2. Những ràng buộc chung của REST

- Không có định nghĩa hoặc tiêu chuẩn cụ thể về REST là gì. Là một khái niệm về kiến trúc - Architecture, REST xác định cách các thành phần khác nhau được liên kết thông qua các trình kết nối và cách dữ liệu được trao đổi qua các giao diện. REST là một loạt các ràng buộc hoặc yêu cầu mà khi tuân theo, sẽ tạo ra việc triển khai kiểu kiến trúc REST.

 

- Kiến trúc REST Architecture không khuyến khích việc tạo ra các phương pháp bổ sung, theo tình huống cụ thể. Ví dụ, một kiến trúc REST Architecture sẽ sử dụng phương thức GET để truy xuất dữ liệu trong mọi trường hợp. Thay đổi duy nhất đối với các loại dữ liệu khác nhau sẽ là các tham số khác nhau. Ngược lại điều này với việc tạo một phương pháp mới để lấy thông tin về người dùng (getUser) và một phương pháp khác để lấy thông tin về giá cả (getPricing), v.v.

 

- Client server (Yêu cầu đối với máy chủ và máy khách)

 

- Stateless (Không trạng thái)

 

 

- Cacheable data (Dữ liệu có thể lưu vào bộ nhớ cache)

 

- Uniform interface (Giao diện thống nhất)

Định danh các tài nguyên (Identification of Resources)

Bất kỳ thông tin nào có thể được đặt tên đều là tài nguyên. Một tài nguyên có thể là bất kỳ dạng dữ liệu nào. Định danh tài nguyên là một cách để tham chiếu đến một tài nguyên cụ thể tại một thời điểm cụ thể. Các tài nguyên đó có thể được cập nhật trên máy chủ mà khách hàng không cần phải có kiến thức trước vì mỗi yêu cầu đều được mô tả và trả lời đầy đủ.

 

Thao khống thông qua biểu tả (Manipulation via representations)

Một biểu tả “Representation” là trạng thái hiện tại của tài nguyên, cùng với siêu dữ liệu (Metadata) đi kèm cho phép hiểu biểu tả đó. Định dạng dữ liệu (data format) của biểu tả xác định loại đa phương tiện (Media Type) của nó. Do đó, máy khách có thể yêu cầu một tài nguyên, chẳng hạn như hình ảnh, từ một máy chủ bằng cách sử dụng mã định danh tài nguyên của tài nguyên đó (có thể là URI) và bản trình bày hình ảnh đó bao gồm các byte tạo nên hình ảnh, cùng với siêu dữ liệu xác định định dạng dữ liệu như một loại phương tiện JPG sẽ được trả lại cho máy khách, sau đó có thể hiển thị hình ảnh cho người dùng.

 

 

Thông điệp tự mô tả (Self-descriptive messages)

Mọi thông báo từ máy khách đến máy chủ phải chứa tất cả các thông tin cần thiết để xử lý thông báo. Trong trường hợp bảo mật và xác thực, mã thông báo bảo mật phải được trao đổi trong mỗi tin nhắn.

Cookie rất phổ biến trên internet. Hành động kiểm tra cookie so với tất cả dữ liệu trong mọi thư sẽ là một ví dụ về thông điệp không tự mô tả và do đó không phải là RESTful về mặt kỹ thuật.

 

 

Siêu phương tiện là Engine của trạng thái ứng dụng (HATEOAS)

 

Định nghĩa siêu phương tiện (Hypermedia): Siêu phương tiện tương tự như khái niệm siêu văn bản (hypertext), hay siêu liên kết (hyperlink), ngoại trừ việc nó bao gồm tất cả các dạng phương tiện chứ không chỉ văn bản hoặc liên kết. Đó là một cách phi tuyến tính để cung cấp thông tin hoặc dữ liệu thường thông qua việc theo một liên kết hoặc điểm đánh dấu khác trong tài nguyên đã xuất bản, chẳng hạn như một trang web. Siêu phương tiện có thể là văn bản, đồ họa, video hoặc các dạng dữ liệu khác.

Theo HATEOAS, khách hàng tương tác qua mạng thông qua siêu phương tiện.

Máy khách tương tác với máy chủ chỉ sử dụng siêu phương tiện. Siêu phương tiện tương tự đó được máy chủ phân phối động theo yêu cầu RESTful request. Do đó, không cần biết trước về dữ liệu trên máy chủ, cấu trúc của nó, cũng như cách dữ liệu đó được lưu trữ. Thay vào đó, chỉ cần sử dụng cấu trúc và phương pháp siêu phương tiện được xác định rõ ràng.

 

- Layered system (Hệ thống phân lớp)

 

- Code on demand (Code theo yêu cầu)

 

 

3. Các thành phần của REST

- Data elements (Các thành phần của dữ liệu)

 

- Resource (Tài nguyên)

 

 

- Resource identifier (Định danh tài nguyên)

 

 

- Representations (Biểu tả)

 

- Representation metadata (Siêu dữ liệu biểu tả)

 

- Resource metadata (Siêu dữ liệu tài nguyên)

 

- Control data (Dữ liệu kiểm soát)

 

4. Triển khai RESTful (RESTful implementation)

- Khi kết hợp với nhau, kiến trúc REST Architecture tạo ra một khung đồng bộ (gọi là Framework) có khả năng mở rộng cao, hoàn toàn minh bạch và có thể tái sử dụng, trong đó các máy khách được tách ra khỏi việc cấy ghép các dịch vụ trên máy chủ. Nó độc lập với nền tảng, cho cả máy khách và máy chủ. Nó là ngôn ngữ và cấu trúc độc lập. Sẽ không có vấn đề gì nếu dữ liệu tồn tại trong cơ sở dữ liệu, được truy xuất bởi các tiến trình của máy chủ Java Server và được gửi đến một chương trình cục bộ - chẳng hạn như trình duyệt - được code bằng một trong một số phiên bản ngôn ngữ lập trình C.

 

- Trên các trang web hiện đại, REST được triển khai bằng cách sử dụng một bảng từ vựng tiêu chuẩn chung giữa máy khách và máy chủ được gọi là Giao thức truyền siêu văn bản (Hypertext Transfer Protocol), hoặc HTTP. Tuy nhiên, bất kỳ triển khai nào phù hợp với tất cả các đối tượng thuê (tenant) của kiến trúc REST đều được coi là triển khai RESTful. HTTP không phải là khả năng duy nhất.

 

5. REST và HTTP

- Mặc dù HTTP và REST không giống nhau, nhưng HTTP là dạng ban đầu và là một triển khai của REST. Điều này không có gì đáng ngạc nhiên khi Roy Fielding đang làm việc trên giao thức HTTP 1.1, đồng thời phát triển kiến trúc REST Architecture.

 

- Identification of resources in HTTP (Nhận dạng tài nguyên trong HTTP)

 

- Representation of resources (Biểu tả các tài nguyên)

 

- HTTP methods (Phương thức HTTP)

 

- Idempotence (Lý tưởng)

 

- GET, POST, PUT, DELETE

 

 

6. RESTful APIs

- Các yêu cầu đối với một RESTful API

 

• Independence of protocol (Tính độc lập của giao thức)

Một RESTful API thực sự không nên phụ thuộc vào bất kỳ giao thức nào và phải có thể hỗ trợ bất kỳ giao thức nào sử dụng URI để nhận dạng. Nếu không, nhận dạng không tách rời khỏi tương tác.

 

• Support of protocols as standardized (Hỗ trợ các giao thức được tiêu chuẩn hóa)

RESTful API không nên yêu cầu thay đổi các giao thức được chuẩn hóa, đặc biệt là việc bổ sung các tính năng bổ sung. Bất cứ khi nào có thể, bất kỳ giải pháp thay thế bắt buộc nào phải được xác định riêng với mục tiêu loại bỏ chúng hoàn toàn khi các giải pháp thay thế không còn cần thiết nữa.

 

• Does not define fixed resources (Không xác định tài nguyên cố định)

Không gian tên máy chủ phải độc lập với định nghĩa và yêu cầu API. Nói cách khác, API phải hoạt động với bất kỳ máy chủ nào có khả năng REST, không chỉ các máy chủ tuân theo một đặc tả API cụ thể.

 

 

 

Nguồn: https://www.paessler.com/it-explained/rest

Dịch: N.V.Hùng