Cơ bản về REST
Bài đăng này đã không được cập nhật trong 9 năm
I. Giới thiệu
- Xu hướng thiết kế web service trước kia từng là SOAP, WSDL ... nhưng hiện nay đã có một phương pháp tốt hơn đó là: REST (Representation State Stranfer).
- REST làm cho ứng dụng trở nên rõ ràng hơn:
- Rõ ràng về URLs: REST URL đại diện cho resource chứ không phải là một hành động.
- Trả về với nhiều định dạng khác nhau: html, xml, rss …
- Code ngắn gọn hơn.
- Rõ ràng cho việc thiết kế ứng dụng.
- REST định nghĩa các quy tắc kiến trúc để bạn thiết kế Web services chú trọng vào tài nguyên hệ thống, bao gồm các trạng thái tài nguyên được định dạng như thế nào và được chuyển tải qua HTTP thông qua số lượng lớn người dùng và được viết bởi những ngôn ngữ khác nhau. Có một số nguyên tắc để thiết kế một ứng dụng Web Service REST:
- "thing" là ID
- Sử dụng các phương thức chuẩn
- Resource với nhiều đại diện
- Giao tiếp phi trạng thái (statelessly)
II. Để mỗi "thing" là một ID
- Mọi thứ phải nên định danh bởi một ID - ở trên web, có một khái niệm thống nhất về IDs là: URI. URIs cấu thành global namespace và sử dụng URI để định danh các khóa resource điều đó có nghĩa chúng là duy nhất, ID toàn cục (global ID).
- Một số ví dụ về URI:
http://example.com/customers/1234
http://example.com/orders/2007/10/776654
http://example.com/products/4554
http://example.com/processes/salary-increase-234
- Một ví dụ tiếp
http://example.com/orders/2007/11Giả định rằng URI trên là một tập các order được thực hiện vào tháng 11 năm 2007. Thì đây là không phải là một "thing" mà là một tập các "thing". (như đã nói trên mỗi thing là một id và được xác định bởi một URI)
III. Sử dụng các phương thức chuẩn
- Mọi resource đều hỗ trợ một số các hành động mà HTTP gọi là các verbs. Các phương thức chuẩn vào gồn PUT, DELETE, HEAD và OPTIONS. Ý nghĩa của các phương pháp này được định nghĩa trong đặc tả HTTP, cùng với một số bảo đảm về hành vi của chúng. Bạn có thể tưởng tượng rằng mọi resource trong RESTfull HTTP được mở rộng từ class:
_class Resource {_
_ Resource(URI u);_
_ Response get();_
_ Response post(Request r);_
_ Response put(Request r);_
_ Response delete();_
_ }_
- Phương thức GET: Sử dụng GET theo cách này rất rõ ràng vì GET chỉ dành cho truy cập dữ liệu. GET không thay đổi giá trị của resource.
- Phương thức PUT: Sử dụng để cập nhật dữ liệu của resource. Dữ liệu được cập nhật bằng cách xác định resource bằng URI. Nếu không tồn tại resource nó sẽ tạo ra một resource mới.
- Phương thức DELETE dùng để xóa resource: xóa resource bởi URI.
- Phương thức POST: tạo ra một resource mới.
-
Trong RESTfull HTTP:
Method Resource Verb_ index posts.xml GET show /posts/1.xml GET create /posts.xml POST update /posts/1.xml PUT delete /posts/1.xml DELETE
IV. Resources với nhiều đại diện
- Làm thế nào một client biết làm thế nào để giải quyết được với các dữ liệu nó lấy được trả về, ví dụ như kết quả của một yêu cầu GET hoặc POST? Phương pháp của HTTP là cho phép một sự tách biệt giữa các mối quan tâm xử lý dữ liệu và gọi hành động. Nói cách khác, một client mà biết làm thế nào để tiếp cận một dạng dữ liệu đặc biệt có thể tương tác với tất cả các resource mà có thể cung cấp một đại diện trong định dạng này.
V. Giao tiếp phi trạng thái
- Nguyên tắc cuối cùng là stateless communication. Trước hết, điều quan trọng cần nhấn mạnh rằng mặc dù REST bao gồm các ý tưởng của statelessness, điều này không có nghĩa là một ứng dụng cho thấy chức năng của nó không thể có state - trong thực tế, điều này sẽ làm cho toàn bộ cách tiếp cận khá vô dụng trong hầu hết các tình huống nếu không có state. REST ám chỉ rằng hoặc là chuyển về resource state, hoặc lưu giữ trên client. Nói cách khác, một máy chủ không cần phải giữ lại một số loại giao tiếp state cho bất kỳ client giao tiếp với hơn một request.
Lý do rõ ràng nhất cho điều này là khả năng mở rộng - số lượng client tương tác sẽ ảnh hưởng nghiêm trọng tới server nếu nó phải giữ state cho client. (Lưu ý rằng điều này thường đòi hỏi một số thiết kế lại - bạn có thể không chỉ đơn giản là gắn một URI vào một số session state và gọi nó là RESTful).
Nhưng có những khía cạnh khác mà có thể quan trọng hơn nhiều: Hạn chế statelessness cô lập các client đối với những thay đổi trên server vì nó không phụ thuộc vào cuộc nói chuyện với cùng một server trong hai request liên tiếp. Một client có thể nhận được một tài liệu có chứa các liên kết từ các máy chủ, và trong khi nó thực hiện một số tiến trình, máy chủ có thể shutdown, đĩa cứng của nó có thể được tách ra và được thay thế, phần mềm có thể được cập nhật và khởi động lại - và nếu client theo dõi một trong các liên kết đã nhận được từ máy chủ, nó sẽ không nhận thấy thông báo.
hình minh họa:
VI. RESTful Routing in Rails 3
1. Controller chuẩn RESTful
Rails hỗ trợ tạo RESTful routes thông qua phương thức resource
file config/routes.rb
resources :products
Khi chạy rake routes ta sẽ có được kết quả như sau:
2. Restful routes
Thông thường thì create và update phải cần đến 2 bước 2 request.
Giả sử khi bạn cần update một product bạn cần phải edit và bước thứ 2 là update product đó. Điều đó cũng giải thích vì sao bạn không cần routes name cho 2 action đó vì action đó liên quan đến submit form.
Create và update methods Rails sẽ tự động sinh ra URLs khi ta sử dụng phương thức form_form
Ví dụ
def new_
@product = Product.new_
end
khi ta gọi form_for(@product) trên view rails sẽ tự sinh ra url form tương ứng
<form action="“/products/1”" method="“post”" >
tương tự ta có hàm edit
def edit
@product = Product.find(params[:id])_
end
khi trên view gọi form_for(@product) rails sẽ tự sinh ra url form tương ứng.
< action="“/products/1”" method="“post”" >
3. PUT và DELETE verb
Như bạn đã thấy ở trên Rails đã sinh ra method post cho trường hợp update trong khi trong routes phương thức cho việc update lại là PUT, tại sao lại có điều này? Thực ra thì trình duyệt chỉ thực hiện 2 phương thức đó là get và post điều đó có nghĩa là tất cả các form trong trình duyệt sẽ được gửi thông qua phương thức post. Để làm được việc này thì rails sẽ thêm hidden field với tên _method với phương thức được gán là put hoặc delete trên server rails sẽ lấy hiddent field và thay đổi phương thức cho phù hợp.
VII. Kết luận
REST không phải là sự lựa chọn luôn đúng. Đã có trường hợp khi thiết kế Web service, nó có sự kém độc lập đối với phần mềm trung gian (ví dụ: một ứng dụng máy chủ) so với loại dựa trên SOAP hặc WSDL. Đưa một tài nguyên hệ thống thông qua một RESTful API là một cách linh động để cung cấp các loại ứng dụng khác nhau với dữ liệu đã được định dạng theo cách tiêu chuẩn. Nó giúp đáp ứng các yêu cầu tích hợp, điều rất quan trọng để xây dựng hệ thống khi dữ liệu được kết hợp dễ dàng và để mở rộng hoặc xây dựng trên một gói hệ thống căn bản.
Một app nhỏ xây dựng rest kết hợp với gem sinatra https://github.com/khanhhd/blog
References
Original: http://www.infoq.com/articles/rest-introduction
Translattion 
https://gist.github.com/khanhhd/6879483
All rights reserved
