REST là gì?

REST là gì?


Nội dung bài viết:

Bạn đang đọc: REST là gì?

1. REST là gì ?
2. Những ràng buộc chung của REST
3. Phần tử REST
4. RESTful thực thi
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 vận dụng cho những ứng dụng được nối mạng ( Networked Applications ). Nó sống sót như một loạt những ràng buộc ( Constraints ) được vận dụng cho việc tiến hành những thành phần mạng, được cho phép ngữ nghĩa giao diện thống nhất, thay vì những tiến hành 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 diễn ”. 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 thay mặt cho bất kể điều gì. Nó chỉ là vần âm 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ư yếu tố đã gây khó khăn vất vả cho GIF trong những năm gần đây. Với chữ E gồm có, không có sự nhầm lẫn khi phát âm từ viết tắt đúng mực hơn của RST là cổ tay “ wrist ” hoặc thậm chí còn 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 đơn cử về REST là gì. Là một khái niệm về kiến trúc – Architecture, REST xác lập cách những thành phần khác nhau được link trải qua những trình liên kết và cách tài liệu được trao đổi qua những giao diện. REST là một loạt những ràng buộc hoặc nhu yếu mà khi tuân theo, sẽ tạo ra việc tiến hành kiểu kiến trúc REST .

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

Client server ( Yêu cầu so với sever và máy khách )

  • Giao diện người dùng trên máy khách (Clients) tách biệt và độc lập với việc lưu trữ dữ liệu trên máy chủ (Servers). Điều này cho phép máy khách được triển khai và sửa đổi bất kể điều gì đang xảy ra trên máy chủ. Tương tự như vậy, dữ liệu trên máy chủ có thể được sử dụng và sửa đổi bất kể máy khách đang truy cập bằng cách nào. Thiết kế như vậy cho phép cả hệ thống máy khách và máy chủ phát triển với tốc độ riêng của chúng, độc lập với nhau.

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

  • Không có dữ liệu phiên (Session Data) nào được lưu trữ trên máy chủ giữa các yêu cầu từ máy khách. Nói cách khác, mọi giao dịch phải mang theo khả năng hiểu yêu cầu hoàn toàn mà không cần truy cập vào bất kỳ ngữ cảnh hoặc dữ liệu bổ sung nào được lưu trữ trên máy chủ. Tất cả dữ liệu phiên phải nằm độc quyền trên máy khách.
  • Ràng buộc này cho phép đơn giản hóa việc cân bằng tải (Load Balancing) hoặc khả năng chịu lỗi (Fault Tolerance). Một máy chủ khác có thể đáp ứng từng và mọi yêu cầu từ máy khách và trả về cùng một dữ liệu mà máy chủ gốc sẽ có, miễn là cả hai máy chủ đều có cùng dữ liệu gốc. Không cần phải chuyển bất kỳ loại dữ liệu phiên cụ thể nào giữa các máy chủ cân bằng tải như vậy. Các phiên không phải là không trạng thái (Stateless) có thể dẫn đến các phản hồi khác nhau nếu yêu cầu được xử lý bởi một máy chủ khác, vì chỉ máy chủ trước đó mới có dữ liệu cụ thể cho phiên đó với máy khách.

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

  • Trong mọi trao đổi, dữ liệu phải được đánh dấu là dữ liệu có thể lưu vào bộ nhớ cache hoặc không thể lưu trong bộ nhớ cache. Dữ liệu có thể lưu vào bộ nhớ cache có thể được máy khách lưu trữ và sử dụng lại. Không có dữ liệu nào được lưu trữ trên máy chủ vì điều này sẽ vi phạm ràng buộc nguyên tắc không trạng thái (Stateless) ở trên. Khả năng lưu trữ dữ liệu vào bộ nhớ cache làm giảm băng thông vì không cần băng thông để duy trì một phiên truy cập máy chủ – máy khách.

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

  • Để đạt được khả năng tương tác đầy đủ, giao diện được tách biệt khỏi loại dữ liệu miễn là tất cả các tương tác hoạt động theo cùng một cách. Bốn ràng buộc phụ đảm bảo giao diện thống nhất: Định danh tài nguyên (Identification of Resources), Thao khống tài nguyên thông qua biểu tả (Manipulation of Resources via Representations), Thông điệp tự mô tả (Self-descriptive Messages) và Siêu phương tiện đóng vai trò Engine của ứng dụng HATEOAS “Hypermedia as The Engine Of the Application State (HATEOAS)”.

Định danh những 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 trải 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ự diễn đạ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 đi lại 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 )

  • Trong hệ thống các lớp phân cấp, không thành phần nào có thể tương tác với hoặc xem bất kỳ dữ liệu hoặc giao diện nào ngoại trừ trên lớp hiện tại của chính nó. Do đó, máy khách không cần biết cách, thậm chí không cần thiết phải kết nối với bất kỳ máy chủ, proxy, tường lửa, bộ định tuyến hoặc điểm cuối bổ sung nào. Thay vào đó, bất kỳ trung gian (intermediary) nào sẽ tiếp tục kết nối với các máy chủ tiếp theo theo các ràng buộc REST và kết quả là phản hồi cho bất kỳ yêu cầu nào được trả lại qua trung gian cho máy khách cũng sẽ tuân thủ REST. Do đó, các thay đổi hoặc gián đoạn đối với hệ thống trung gian là vô hình đối với máy khách cho phép các hệ thống trung gian đó cung cấp cân bằng tải, bảo mật hoặc các chức năng khác.

Code on demand ( Code theo nhu yếu )

  • Mặc dù về mặt kỹ thuật được gắn nhãn là tùy chọn, các máy khách trong kiến trúc REST sẽ có thể tải xuống và thực thi các tập lệnh. Điều này cho phép mở rộng các chức năng và hệ thống phức tạp hơn, trong khi vẫn cung cấp giao tiếp kiểu REST giống nhau giữa máy khách và máy chủ. Như với các yêu cầu và phản hồi cơ bản, toàn bộ hướng dẫn chạy mã đã tập lệnh (scripted code) phải độc lập và không yêu cầu triển khai trước trên máy khách.
  • Ví dụ: một ứng dụng khách web (web client) có thể thực thi JavaScript mà nó nhận được từ máy chủ. Mặc dù Code nằm trên máy chủ, nhưng nó không được thực thi ở đó. Thay vào đó, bản thân Code được gửi đến máy khách như một phần của yêu cầu và code đó được máy khách thực thi theo cách triển khai của nó. Đây là lý do tại sao việc triển khai các tiêu chuẩn thích hợp trong các ứng dụng khách web là rất quan trọng; nếu không, cùng một mã từ máy chủ có thể được thực thi với các kết quả khác nhau trên các máy khách khác nhau.


 

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


Data elements ( Các thành phần của tài liệu )

  • Các thành phần của hệ thống REST giao tiếp thông qua đặc tả tài nguyên ở một trong số các định dạng tiêu chuẩn hóa đã thống nhất như định dạng đồ họa (graphic formats), định dạng tài liệu (document formats) và các định dạng web (web formats) khác nhau. Một lần nữa, để trở thành một hệ thống REST thực sự, mỗi giao dịch phải có khả năng truy xuất và diễn giải tài nguyên mong muốn.

 

Resource ( Tài nguyên )

  • Resource (Tài nguyên) là bất cứ thứ gì có thể được đặt tên. Tài nguyên được lưu trữ trên máy chủ được máy khách yêu cầu. Tài nguyên có thể là tệp tĩnh (static file), tài liệu (document), cơ sở dữ liệu (database), ảnh (picture) hoặc bất kỳ định dạng nào khác có thể được yêu cầu.
  • Mặc dù bây giờ là một khái niệm phổ biến, nhưng ý tưởng ban đầu về tài nguyên như một phần tử thời điểm chung, có thể thay đổi, là đặc điểm chính của REST và web nói chung. Tài nguyên là bất kỳ dữ liệu có thể đặt tên nào trên máy chủ. Dữ liệu đó không chỉ có thể thay đổi thành phiên bản mới hơn của cùng một dữ liệu, mà thậm chí thành một loại dữ liệu hoàn toàn khác. Điều này cho phép dữ liệu trên máy chủ được cập nhật bất kỳ lúc nào mà không cần bất kỳ máy khách nào biết trước về nó, một tính năng chính của khả năng tương tác và tính khả dụng.

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

  • Resource identifier (Định danh tài nguyên) là vị trí cụ thể của tài nguyên được yêu cầu. Trong trường hợp hệ thống dựa trên HTTP, định danh tài nguyên là URL hoặc URI. Định danh tài nguyên chỉ định một tài nguyên. Một mã định danh tài nguyên duy nhất có thể tham chiếu đến dữ liệu hoặc tài nguyên khác nhau vào những thời điểm khác nhau. Trong một hệ thống tuân thủ REST, máy khách không cần biết trước loại tài nguyên mà định danh tài nguyên đang yêu cầu. Phản hồi sẽ bao gồm siêu dữ liệu mô tả cách diễn giải dữ liệu nhận được.
  • Ví dụ: ngay cả khi yêu cầu URL có trạng thái là “/server/index.html”, nếu tài nguyên tại địa chỉ đó trả về biểu diễn dưới dạng tệp hình ảnh, cùng với siêu dữ liệu tương ứng, tệp hình ảnh sẽ vẫn được hiển thị chính xác bất kể tài nguyên là gì, định danh tài nguyên sẽ cho biết.

Representations ( Biểu tả )

  • Biểu tả đề cập đến dữ liệu được gửi đến máy khách. Như đã đề cập ở trên, biểu tả phải là một trong những định dạng dữ liệu được chuẩn hóa. Dữ liệu không được xử lý trên máy chủ mà được máy khách thông dịch. Ví dụ: một ứng dụng khách yêu cầu một tài liệu HTML không nhận được một đồ họa để hiển thị trên màn hình, mà là một tập hợp mã HTML code sau đó được diễn giải và hiển thị trên ứng dụng khách. Các ví dụ biểu tả khác bao gồm các tệp đồ họa như ảnh JPEG và GIF.

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

  • Representation metadata (Siêu dữ liệu biểu ta) cung cấp thông tin trình bày cho hệ thống. Cũng giống như với hầu hết các siêu dữ liệu, siêu dữ liệu biểu tả thường không phải là một phần của những gì được hiển thị cho người dùng cuối. Siêu dữ liệu biểu tả có thể bao gồm thông tin về loại phương tiện (media type), ngày tạo (created date) và sửa đổi (modified date) cũng như số phiên bản (version number).

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

  • Siêu dữ liệu tài nguyên là thông tin bổ sung được cung cấp cho hệ thống về tài nguyên tồn tại trên máy chủ chứ không phải là thông tin trình bày về tài nguyên được hiển thị trên máy khách. Ví dụ về siêu dữ liệu tài nguyên bao gồm liên kết nguồn (source links), hiển thị thay thế (alternates) và thông tin về tài nguyên. Ví dụ: siêu dữ liệu tài nguyên có thể bao gồm văn bản thay thế được hiển thị trong trường hợp không thể hiển thị biểu diễn hình ảnh vì một số lý do (ví dụ: văn bản hình ảnh ALT trong HTML).

Control data ( Dữ liệu trấn áp )

  • Dữ liệu kiểm soát chủ yếu quan tâm đến tính hợp lệ của tài nguyên và sự thể hiện trình bày của nó trên máy khách. Dữ liệu kiểm soát bao gồm việc dữ liệu có thể lưu vào bộ nhớ cache hay không, cũng như thời gian hết hạn tuyệt đối (Expiry Time) hoặc cung cấp giới hạn về thời lượng dữ liệu được sử dụng. Dữ liệu kiểm soát cũng có thể bao gồm Checksum hoặc các phương tiện khác để đảm bảo tính toàn vẹn.

 

4. Triển khai RESTful (RESTful implementation)

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

– Trên những website văn minh, REST được tiến hành 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à sever đượ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ể tiến hành nào tương thích với toàn bộ những đối tượng người tiêu dùng thuê ( tenant ) của kiến trúc REST đều được coi là tiến hành RESTful. HTTP không phải là năng lực duy nhất .

5. REST và HTTP

– Mặc dù HTTP và REST không giống nhau, nhưng HTTP là dạng bắt đầu và là một tiến hành của REST. Điều này không có gì đáng kinh ngạc khi Roy Fielding đang thao tác trên giao thức HTTP 1.1, đồng thời tăng trưởng kiến trúc REST Architecture .

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

  • Mỗi tài nguyên được xác định bởi một Mã Định Danh Tài Nguyên Duy Nhất URI (URI – Uniform Resource Identifier). Thông thường, điều này được triển khai dưới dạng URL trong trình duyệt web. URI xác định một tài nguyên. Không có kiến thức trước về hệ thống nơi tài nguyên nằm trên máy chủ là bắt buộc. Ngoài ra, URI (hoặc URL) có thể chỉ định đại diện của một tài nguyên mà không cần biết về cấu trúc tệp của tài nguyên đó.

Representation of resources ( Biểu tả những tài nguyên )

  • Trong HTTP, việc trình bày tài nguyên được thực hiện thông qua hỗ trợ cho nhiều loại tệp khác nhau trong trình duyệt HTTP. Do đó, siêu dữ liệu đi kèm với tài nguyên xác định một trong số các định dạng tệp được hỗ trợ rộng rãi như HTML, CSS, JPG, GIF, v.v.

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

  • Việc triển khai REST thuần túy của HTTP yêu cầu sử dụng bốn phương thức cốt lõi (Core Methods) là GET, POST, PUT và DELETE. Mỗi phương thức phải được sử dụng một cách rõ ràng và được ánh xạ tới một trong từng hành động cốt lõi XÁC LẬP DỮ LIỆU (RETRIEVE DATA), TẠO TÀI NGUYÊN (CREATE RESOURCE), CẬP NHẬT TÀI NGUYÊN (UPDATE RESOURCE) và XÓA TÀI NGUYÊN (DELETE RESOURCE).

Idempotence ( Lý tưởng )

  • Một số phương thức HTTP method nhất định phải là lý tưởng. Lý tưởng có nghĩa là việc thực thi cùng một phương thức với các tham số giống nhau sẽ luôn trả về cùng một kết quả. Để điều này hoạt động, phương thức (method) được đề cập không thể gây ra bất kỳ sửa đổi nào trên máy chủ khiến kết quả khác được trả về cho cùng một yêu cầu. Trong các khía cạnh thực tế, một yêu cầu không nên thay đổi dữ liệu dựa trên máy chủ.

GET, POST, PUT, DELETE

  • Được sử dụng để lấy một tài nguyên hoặc thông tin về tài nguyên đó. Mặc dù hầu hết các triển khai HTTP sẽ xử lý các tham số (parameters) với yêu cầu GET để sửa đổi (modify) hoặc tạo (create) tài nguyên, nhưng hành động như vậy sẽ không tuân thủ triển khai RESTful. Yêu cầu GET phải là lý tưởng.
  • Yêu cầu POST tạo dữ liệu mới trên máy chủ. Theo định nghĩa, một yêu cầu POST sẽ KHÔNG phải là lý tưởng. Với mỗi lần thực thi, một yêu cầu POST sẽ tạo ra nhiều dữ liệu hơn.
  • Tương tự như yêu cầu POST, yêu cầu PUT sửa đổi dữ liệu hiện có. Ví dụ: thay đổi họ của người dùng hiện tại. Các yêu cầu PUT không phải là lý tưởng. Mặc dù một yêu cầu PUT thực hiện thay đổi dữ liệu, nhưng nó thực hiện theo cùng một cách mọi lúc. Do đó, việc chạy một yêu cầu PUT thay đổi họ của người dùng sẽ luôn tạo ra cùng một kết quả miễn là tất cả các tham số đều nhất quán.
  • Yêu cầu DELETE gỡ bỏ hoặc xóa dữ liệu, đúng như tên của yêu cầu này. Yêu cầu DELETE cũng rất quan trọng ở chỗ việc chạy lặp lại một yêu cầu sẽ luôn dẫn đến cùng một trạng thái cuối cùng với dữ liệu được đề cập không còn tồn tại trên máy chủ. Tuy nhiên, đối với máy khách, có thể có sự khác biệt ở chỗ khi tài nguyên bị xóa, yêu cầu có thể được trả lời với một thông báo lỗi chẳng hạn như không tìm thấy tệp. Tuy nhiên, phương thức (method) này vẫn được coi là không lý tưởng, bởi vì bất kể lỗi nào được gửi trong quá trình giao dịch, trạng thái kết thúc của một yêu cầu như vậy vẫn giống như lần đầu tiên nó được yêu cầu.

6. RESTful APIs

– Các nhu yếu so với một RESTful API

  • Trong một bài đăng trên blog hiện đã bị bỏ rơi của mình, Roy Fielding đã thảo luận về những tiêu chí mà một API phải đáp ứng để được coi là thực sự RESTful. Dựa trên luận điểm đã xuất bản trước đây của Roy Fielding, bài đăng này mô tả các khái niệm kiến trúc REST Architecture giống như chúng nên áp dụng cho các API.
  • Do đó, một API RESTful là một API mà nó CHỈ sử dụng kiến trúc REST Architecture mà không cần thêm tài liệu hoặc phương thức ngoài những thứ phù hợp với mô hình. Fielding cung cấp các điểm sau để làm rõ điều gì khiến REST API tuân thủ.

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ể.

 


 

Dịch : N.V.Hùng