Roger L. Costello

Trước tiên tôi sẽ cung cấp một giới thiệu ngắn gọn về REST sau đó mô tả làm thế nào để xây dựng các dịch vụ Web theo phong cách REST.

REST là gì?

REST là một thuật ngữ do Roy Fielding viết trong luận án bằng tiến sĩ của ông ấy [1] để mô tả một phong cách kiến trúc của hệ thống mạng. REST là một từ viết tắt thường trực đại diện cho Representational State Transfer- Chuyển tải trạng thái đại diện.

Tại sao lại gọi là Representational State Transfer?

Các Web bao gồm các nguồn tài nguyên thông tin. Tài nguyên thông tin là bất kỳ sản phẩm được quan tâm. Ví dụ, các phi cơ Boeing Corp có thể định nghĩa tài nguyên 747. Khách hàng có thể truy cập tài nguyên đó với URL này:

http://www.boeing.com/aircraft/747

Một Representational- đại diện của nguồn tài nguyên thông tin được trả lại (ví dụ, Boeing747.html). Các đại diện đặt ứng dụng khách hàng (client application) trong một tổ chức (State). Kết quả của các máy khách vượt qua một siêu liên kết trong Boeing747.html là một tài nguyên khác được truy cập. Các đại diện mới sẽ đặt ứng dụng máy khách vào một tiểu bang khác. Vì vậy, các ứng dụng khách hàng thay đổi (Transfer-chuyển) State với mỗi đại diện tài nguyên -> Chuyển tải trạng thái đại diện -Representational State Transfer!

Dưới đây là lời giải thích của Roy Fielding về ý nghĩa của Representational State Transfer:

"Representational State Transfer là nhằm gợi lên một hình ảnh mà một ứng dụng Web được thiết kế hành xử: một mạng lưới các trang web (một nhà máy ảo), nơi các tiến triển người dùng thông qua một ứng dụng bằng cách chọn liên kết (chuyển trạng thái), kết quả trong trang tiếp theo (đại diện cho các trạng thái kế tiếp của ứng dụng) được chuyển giao cho người sử dụng và kết xuất sử dụng của họ. "

Động cơ của REST

Động cơ thúc đẩy của REST là để nắm bắt các đặc tính của Web nhằm thực hiện các Web thành công. Sau đó những đặc tính đang được sử dụng để hướng dẫn sự tiến triển của Web.

REST – Một Phong cách kiến trúc, Không phải là một tiêu chuẩn cơ bản

REST của không phải là một tiêu chuẩn. Bạn sẽ không thấy các W3C đặt ra một đặc điểm kỹ thuật REST. Bạn sẽ không thấy IBM hay Microsoft hoặc Sun bán bộ công cụ phát triển về REST . Tại Sao? Bởi vì REST là chỉ là một phong cách kiến trúc. Bạn không thể kìm nén kiểu đó. Bạn chỉ có thể hiểu được nó, và thiết kế các dịch vụ Web của bạn trong phong cách đó. (Tương tự như các phong cách kiến trúc máy khách-server . Chứ không có tiêu chuẩn máy khách-server.)

Trong khi REST không phải là một tiêu chuẩn, nó vẫn dùng tiêu chuẩn sử dụng:

• HTTP

• URL

• XML / HTML / GIF / JPEG / etc (Resource Respresentations)

• text / xml, text / html, image / gif, image / jpeg, vv (Các loại MIME)

Hệ thống cổ điển REST

Web là một hệ thống REST! Nhiều người trong số những dịch vụ Web mà bạn đã được sử dụng trong nhiều năm qua – dịch vụ chọn- đặt hàng, dịch vụ tìm kiếm, dịch vụ từ điển trực tuyến vv – là dịch vụ Web dựa trên REST. Chao ôi, bạn đã được sử dụng REST, xây dựng các dịch vụ REST và bạn thậm chí còn không biết điều đó.

REST liên quan với những "bức tranh lớn" của Web. Nó không đối phó với các chi tiết thực hiện (ví dụ, bằng cách sử dụng Java servlets hoặc CGI để thực hiện một dịch vụ Web). Vì vậy, chúng ta hãy xem xét một ví dụ của việc tạo ra một dịch vụ Web từ quan điểm "bức tranh lớn" REST.

Các bộ phận kho chứa- Depot Dịch vụ Web

Các bộ phận Depot, Inc (công ty ảo) đã triển khai một số dịch vụ web cho phép khách hàng của mình để:

• có được một danh sách của các bộ phận

• có được thông tin chi tiết về một phần cụ thể

• nộp về Đơn đặt hàng (PO)

Hãy nghĩ xem làm thế mỗi dịch vụ được thực hiện theo một RESTful fashion.

Nhận danh sách các bộ phận

Các dịch vụ web làm sẵn về URL đến một nguồn tài nguyên thông tin danh sách các phần. Ví dụ, một khách hàng sẽ sử dụng URL này để có được danh sách các phần:

http://www.parts-depot.com/parts

Lưu ý rằng "làm thế nào" các dịch vụ web tạo ra danh sách các phần là hoàn toàn rõ ràng cho khách hàng. Tất cả các khách hàng biết là nếu anh ấy / cô ấy submit URL ở trên sau đó tài liệu có chứa danh sách của các bộ phận được trả về. Kể từ khi triển khai thực hiện là minh bạch cho khách hàng, bộ phận Depot là miễn phí để sửa đổi thực hiện cơ bản của tài liệu này mà không ảnh hưởng đến khách hàng. Đây là khớp nối lỏng.

Dưới đây là những tài liệu mà khách hàng nhận được:

<?xml version="1.0"?>


<p:Parts xmlns:p="http://www.parts-depot.com"


        xmlns:xlink="http://www.w3.org/1999/xlink">


     <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>


     <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>


     <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>


     <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>


</p:Parts>

[Giả sử rằng thông qua đàm phán nội dung dịch vụ xác định rằng khách hàng muốn các đại diện như XML (dùng cho máy-sang máy xử lý.] Lưu ý rằng danh sách các bộ phận có liên kết để có được thông tin chi tiết về mỗi phần. Đây là về tính năng quan trọng của REST. Việc chuyển máy khách từ một state sang một trang tiếp theo bằng cách kiểm tra và lựa chọn trong số các URL thay thế trong văn bản trả lời.

Nhận Chi tiết Phần dữ liệu

Các dịch vụ web làm sẵn về URL cho mỗi tài nguyên phần. Ví dụ, đây là cách về khách hàng yêu cầu một phần 00345:

http://www.parts-depot.com/parts/00345

Dưới đây là tài liệu mà khách hàng nhận được:

<?xml version="1.0"?>


<p:Part xmlns:p="http://www.parts-depot.com"   


       xmlns:xlink="http://www.w3.org/1999/xlink">


     <Part-ID>00345</Part-ID>


     <Name>Widget-A</Name>


     <Description>This part is used within the frap assembly</Description>


     <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>


     <UnitCost currency="USD">0.10</UnitCost>


     <Quantity>10</Quantity>


</p:Part>

 

Một lần nữa quan sát cách dữ liệu này được liên kết với nhiều dữ liệu hơn nữa – các đặc điểm kỹ thuật cho phần này có thể được tìm thấy bằng cách vượt qua các siêu liên kết. Mỗi tài liệu đáp ứng cho phép khách hàng đi sâu xuống để có được thông tin chi tiết hơn.

Gửi PO

Các dịch vụ web làm sẵn có về URL để gửi một PO. Các khách hàng tạo ra về PO dụ tài liệu đó phù hợp với các giản đồ PO rằng Các bộ phận Depot đã thiết kế (và công bố công khai trong một tài liệu WSDL). Các khách hàng nộp PO.xml như payload về một POST HTTP.

Các PO dịch vụ đáp ứng các POST HTTP với một URL đến một PO được nộp. Như vậy, khách hàng có thể lấy PO tại thời điểm sau đó (để cập nhật / chỉnh sửa nó). Các PO đã trở thành một phần của thông tin được chia sẻ giữa các máy khách và máy chủ. Các thông tin được chia sẻ (PO) được cho một địa chỉ (URL) của các máy chủ và được tiếp xúc như là một dịch vụ Web.

URL Logical so với các URL Physical

Tài nguyên thông tin là một tổ chức khái niệm. Một đại diện là một biểu hiện cụ thể của tài nguyên. Với URL :

http://www.parts-depot.com/parts/00345

là một Với URL logic, không phải là một Với URL physical. Như vậy, có không cần phải được như vậy, ví dụ, một trang HTML tĩnh điện cho từng phần. Trong thực tế, nếu có một triệu bộ phận sau đó một triệu trang HTML tĩnh điện sẽ không có một thiết kế hấp dẫn cho lắm.

[Chi tiết thi hành: Phần Depot có thể thực hiện các dịch vụ đó được dữ liệu chi tiết về một phần cụ thể bằng cách sử dụng một Servlet Java được phân tích các chuỗi sau tên host, sử dụng một phần số để truy vấn cơ sở dữ liệu các phần, xây dựng các kết quả truy vấn như XML, và sau đó trở về XML như là tải trọng của các phản ứng HTTP.]

Như một vấn đề của theo phong cách URL không nên tiết lộ các kỹ thuật triển khai thực hiện được sử dụng. Bạn cần phải được tự do để thay đổi triển khai của bạn mà không ảnh hưởng đến khách hàng hoặc có các URL gây hiểu lầm.

Các đặc tính Dịch vụ Web REST

Dưới đây là những đặc điểm của REST:

• Client-Server: một phong cách tương tác theo mô hình pull: các thành phần tiêu thụ kéo các đại diện.

• Stateless- Phi trạng thái: mỗi yêu cầu từ máy khách đến máy chủ bạn cần phải chứa tất cả các thông tin cần thiết để hiểu yêu cầu và không thể tận dụng lợi thế của bất kỳ ngữ cảnh được lưu trữ trên máy chủ.

• Cache: để cải thiện phản ứng hiệu quả mạng phải có khả năng được dán nhãn là khả năng lưu nhớ hay không khả năng lưu nhớ.

• Giao diện thống nhất: tất cả các nguồn tài nguyên được truy cập với một giao diện chung (ví dụ, HTTP GET, POST, PUT, DELETE).

• Tài nguyên có tên – hệ thống bao gồm các nguồn tài nguyên thông tin được đặt tên bằng cách sử dụng một địa chỉ URL.

• Đại diện tài nguyên liên kết với nhau – cơ quan đại diện của các nguồn lực được kết nối với nhau bằng cách sử dụng các URL, do đó cho phép khách hàng xử lý từ một state khác.

• Thành phần lớp – trung gian, chẳng hạn như các máy chủ proxy, máy chủ cache, các cổng, vv, có thể được chèn vào giữa khách hàng và các nguồn lực để hỗ trợ hiệu suất, an ninh, vv

Nguyên tắc của Thiết kế Dịch vụ Web trên REST

1. Chìa khóa để tạo ra dịch vụ Web trong một mạng REST (tức là, các Web) là xác định tất cả các thực thể khái niệm rằng bạn muốn để lộ tả như dịch vụ. Trên đây chúng ta đã thấy một số ví dụ về các nguồn tài nguyên thông tin: danh sách các bộ phận, phần dữ liệu chi tiết, đơn đặt hàng.

2. Tạo một địa chỉ URL cho mỗi tài nguyên. Các nguồn lực cần có danh từ, chứ không phải động từ . Ví dụ, không sử dụng điều này:

 

http://www.parts-depot.com/parts/getPart?id=00345

Lưu ý các động từ, getPart. Thay vào đó, sử dụng một danh từ:

    http://www.parts-depot.com/parts/00345

3. Phân loại các nguồn lực của bạn theo quy định dù khách hàng chỉ có thể nhận được một đại diện của nguồn tài nguyên thông tin, hoặc cho dù khách hàng có thể thay đổi (thêm vào) các tài nguyên. Đối với các cũ trước, làm cho những nguồn tài nguyên có thể truy cập bằng cách sử dụng một HTTP GET. Đối với các sau mới, làm cho những nguồn tài nguyên có thể truy cập bằng cách sử dụng HTTP POST, PUT, và / hoặc DELETE.

4. Tất cả các nguồn tài nguyên có thể truy cập thông qua HTTP GET nên gây tác dụng phụ miễn phí. Đó là, các nguồn tài nguyên chỉ phải trả lại một đại diện của các tài nguyên. Gọi trình nguồn tài nguyên không nên lây kết quả  trong việc sửa đổi các tài nguyên.

5. Không có người đàn ông / phụ nữ làm nên một hòn đảo. Tương tự như vậy, không có đại diện làm nên  hòn đảo. Nói cách khác, đưa các siêu liên kết trong cơ quan đại diện tài nguyên để cho phép khách hàng đi sâu xuống để biết thêm thông tin, và / hoặc để có được thông tin liên quan.

6. Thiết kế tiết lộ dữ liệu dần dần. Không tiết lộ tất cả mọi thứ trong một tài liệu phản ứng duy nhất. Cung cấp các siêu liên kết để biết thêm chi tiết.

7. Xác định định dạng của dữ liệu phản ứng bằng cách sử dụng một lược đồ (DTD, Schema W3C, RelaxNG hoặc Schematron). Đối với những dịch vụ đòi hỏi một POST hoặc PUT với nó, cũng cung cấp một lược đồ để xác định định dạng của đáp ứng.

8. Mô tả cách thức các dịch vụ của bạn sẽ được triệu gọi bằng cách sử dụng một tài liệu WSDL, hoặc chỉ đơn giản là một tài liệu HTML.

 

Tóm lược

Bài viết này mô tả về REST như một phong cách kiến trúc. Trong thực tế, đó là phong cách kiến trúc của Web. REST được mô tả những gì làm cho Web hoạt động tốt. Tôn trọng những nguyên tắc REST sẽ làm cho dịch vụ của bạn làm việc tốt trong điều kiện của Web.

Trong một bài viết trong tương lai tôi sẽ viết về sự phát triển của Web bằng cách sử dụng các nguyên tắc REST.

Lời cảm ơn

 

Chân thành cảm ơn đến Robert Leftwich và Philip Eskelin cho ý kiến rất hữu ích của họ trong việc tạo ra văn bản này.

Tài liệu tham khảo

[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm