##Một bài viết ngắn giới thiệu về REST
Bạn có thể hoặc không thể biết được rằng về 1 phương pháp chính xác để thực hiện việc giao tiếp không đồng nhất giữa các ứng dụng với nhau(heterogeneous application-to-application communication): Trong khi xu hướng hiện nay là tập trung vào các dịch vụ Web dựa trên SOAP, WSDL và WS – Tuy nhiên, có một bộ phận nhỏ nhưng vô cùng quan trọng, khẳng định rằng có 1 phương pháp tốt hơn: đó là REST, viết tắt của cụm từ REpresentational State Transfer.
Trong bài viết này, tôi sẽ cố gắng cung cấp một bài giới thiệu có tính chất thực tế về tích hợp ứng dung REST và RESTful HTTP. Tôi sẽ đi vào chi tiết hơn trong khi giải thích những khía cạnh mà theo kinh nghiệm của tôi, gây ra nhiều cuộc thảo luận nhất khi một người nào đó được tiếp xúc với phương pháp này lần đầu tiên.
##Nguyên tắc chính của REST
Hầu hết những bài giới thiệu về REST bắt đầu với định nghĩa và kiến thức chung. Nhưng tôi sẽ không đề cập đến việc này trong 1 thời gian và đưa ra 1 định nghĩa đơn giản và thực tế: “REST là 1 tập hợp những nguyên lý để xác định thế nào là những tiêu chuẩn của Web, giống như HTTP và URIs, được đưa ra sử dụng (thường khác 1 chút so với những gì người ta thực sự làm). Tôi hứa là nếu các bạn tuân thủ nguyên tắc REST khi thiết kế ứng dụng của bạn, bạn sẽ kết thúc với 1 hệ thống mà nó khai thác kiến trúc của Web để tạo ra lợi ích cho bạn. Tóm lại, 5 nguyên tắc chính là:
- Đưa cho tất cả mọi “thứ” 1 ID
- Liên kết mọi thứ với nhau.
- Sử dụng các hàm tiêu chuẩn.
- Resources với nhiều cách biểu diễn
- Giao tiếp một cách phi trạng thái (Communicate statelessly)
Bây giờ, chúng ta sẽ đi sâu và những nguyên tắc này. ###1. Đưa cho tất cả mọi “thứ” 1 ID Tôi đang sử dụng thuật ngữ "thứ" ở đây thay vì dùng từ chính xác "resource" vì đây là một nguyên tắc đơn giản vậy nên nó không nên bị ẩn đi đằng sau một thuật ngữ. Nếu bạn nghĩ về các hệ thống mà con người xây dựng, thường có một tập hợp các khái niệm trừu tượng quan trọng nào đó đáng được xác định. Tất cả mọi thứ cần được định danh rõ ràng bởi một ID – Trong thế giới Web, có 1 khái niệm thống nhất cho ID: đó là URI (Uniform Resource Identifier). URIs cấu thành global namespace, và sử dụng URI để định danh những resources chủ yếu của bạn nghĩa là nó có 1 ID duy nhất, toàn cầu.
Lợi ích chính của hệ thống đặt tên thống nhất là bạn không cần phải đưa ra cấu trúc riêng của mình – bạn có thể dựa vào những gì đã được xác định rõ, làm việc khá tốt trên quy mô toàn cầu. và được hiểu bởi bất kỳ ai trong thực tế. Nếu bạn đang xem xét một high-level object bất kỳ trong ứng dụng gần nhất mà bạn đã xây dựng (giả sử nó không được xây dựng theo phương pháp RESTful), thì rất có thể có nhiều trường hợp bạn được hưởng lợi từ điều này. Ví dụ nếu ứng dụng của bạn bao gồm Customer abstraction, thì tôi có lý do để tin chắc rằng người dung có thể gửi 1 link đến 1 khách hang cụ thể thông qua email cho đồng nghiệp, tạo bookmark cho nó trên trình duyệt, hoặc thậm chí ghi nó trên một mảnh giấy. Nhấn mạnh vào điểm này: Tưởng tượng nếu trang Amazon.com không thể xác định được từng sản phẩm của họ qua ID duy nhất (URI), thì đó là 1 điều kinh khủng.
Khi đối mặt với ý tưởng này, nhiều người tự hỏi rằng điều này có nghĩa là họ nên đưa ra các mục cơ sở dữ liệu (hoặc IDs của chúng) một cách trực tiếp – và thật kinh hoàng vì đây mới đơn thuần chỉ là ý tưởng, từ những năm làm việc về hướng đối tượng đã dạy cho chúng tôi phải ẩn những khía cạnh về persistence như là yêu câu chi tiết cho việc thực thi. Nhưng ở đây không bị xung đột gì cả. Thông thường – những “thứ” – Resource - đáng được định danh với một URI trừu tượng hơn rất nhiều so với một mục cơ sở dữ liệu.
Ví dụ, Order resource có thể bao gồm order items, địa chỉ và rất nhiều khía cạnh khác mà có thể bạn không muốn đưa ra như là những resource có thể định danh được.
Lấy ý tưởng của việc định danh mọi thứ mà đáng được định danh tiếp tục dẫn đến việc tạo ra các resource mà bạn thường không nhìn thấy trong một ứng dụng thiết kế thông thường: Một quá trình hoặc tiến trình, bán hàng, đàm phán , yêu cầu báo giá -tất cả những điều này là ví dụ về "những điều" mà đáng được xác định . Điều này, lần lượt, có thể dẫn đến việc định danh thêm nhiều persistent entities hơn trong một thiết kế không RESTful.
Đây là 1 vài ví dụ về URIs mà bạn có thể xem qua:
http://example.com/customers/1234
http://example.com/orders/2007/10/776654
http://example.com/products/4554
http://example.com/processes/salary-increase-234Như tôi đã chọn để tạo nên những URIs mà con người có thể đọc được – 1 khái niệm hữu ích, mặc dù đó không phải là yêu cầu ban đầu cho một thiết kế RESTful, nó khá là dễ dàng để đoán đc nghĩa: Chúng rõ ràng là định danh những item riêng rẽ. Nhưng hãy nhìn xem:
http://example.com/orders/2007/11
http://example.com/products?color=greenĐầu tiên, những thứ này thể hiện những thứ khác nhau, sau tất cả, chúng đang không định danh 1 thứ, mà cũng không là 1 tập hợp nhiều thứ (giả sử URI đầu tiên xác định tất cả đơn hàng gửi vào 11/2007, và URI thứ 2 là tập hợp các sản phẩm có màu xanh lá cây). Mà những tập hợp này là những thứ thực tế - resources và chúng nên định danh một các rõ ràng.
Lưu ý tới những lợi ích của việc chỉ có duy nhất, hệ thống đặt tên thống nhất trên toàn cầu áp dụng cho cả việc sử dụng các trang web trong trình duyệt của bạn và giao tiếp giữa máy-và-máy.
Tổng kết nguyên tắc đầu tiên: Sử dụng URI để định danh cho mọi thứ đáng ra có thể được định danh, một cách cụ thể, tất cả các resource "cao cấp" mà ứng dụng của bạn cung cấp, cho dù chúng đại diện cho các item riêng biệt, bộ sưu tập các mặt hàng, các đối tượng ảo và vật lý, hoặc kết quả tính toán.
###2. Kết nối mọi thứ với nhau Nguyên lý tiếp theo, chúng ta sẽ xem xét 1 cách miêu tả mà hơi khó một chút: “Hypermedia as the engine of application state ”. thỉnh thoảng, viết tắt là (HATEOAS). Tại cốt lõi của nó là khái niệm về hypermedia ( siêu phương tiện truyền thông), hoặc là 1 từ khác: ý tưởng của các liên kết. Các liên kết là 1 thứ gì đó chúng ta quen với HTML, nhưng chúng không giới hạn sự tiêu dung của con người. Hay xem đoạn code XML sau:
<order self='http://example.com/customers/1234' >
<amount>23</amount>
<product ref='http://example.com/products/4554' />
<customer ref='http://example.com/customers/1234' />
</order> Nếu bạn nhìn vào các liên kết sản phẩm và khách hàng trong tài liệu này, bạn có thể dễ dàng tưởng tượng một ứng dụng đã lấy nó có thể truy vấn theo các liên kết để lấy thêm thông tin. Tất nhiên, đây sẽ là trường hợp nếu có một "id" thuộc tính đơn giản tôn trọng một số quy tắc hoặc hệ thống đặt tên ứng dụng cụ thể, nhưng chỉ trong bối cảnh của ứng dụng. Cái hay của phương pháp tiếp cận liên kết sử dụng các URI là các liên kết có thể trỏ đến các resource được cung cấp bởi một ứng dụng, một máy chủ khác nhau, hoặc thậm chí một công ty khác nhau trên lục địa khác - bởi vì các sơ đồ đặt tên là một tiêu chuẩn toàn cầu, tất cả các resource tạo nên các trang web có thể được liên kết với nhau.
Có một khía cạnh quan trọng hơn về các nguyên tắc hypermedia - phần "state" của ứng dụng. Trong ngắn hạn, thực tế là các máy chủ (hoặc nhà cung cấp dịch vụ) cung cấp một tập hợp các liên kết đến các khách hàng (người tiêu dùng dịch vụ) cho phép khách hàng để di chuyển các ứng dụng đến state tiếp theo bằng cách đi theo một liên kết. Chúng tôi sẽ xem xét những ảnh hưởng của khía cạnh này trong một bài viết sắp tới, vì thời điểm này, chỉ cần lưu ý rằng liên kết là một cách rất hữu ích để làm cho một ứng dụng động.
Tổng kết các nguyên tắc này: Sử dụng các liên kết để tham khảo những thứ có thể được định danh (resources) bất cứ nơi nào có thể. Siêu liên kết là những gì làm nên Web.
###3. Sử dụng các hàm tiêu chuẩn
Có 1 sự giả định ngầm trong 2 nguyên tắc đầu tiên: đó là các ứng dụng thực sự có thể làm điều gì đó có ý nghĩa với các URI. Nếu bạn thấy một URI được viết ở mặt bên của một chiếc xe buýt, bạn có thể nhập vào trường địa chỉ của trình duyệt và nhấn Enter - nhưng làm thế nào để trình duyệt của bạn biết phải làm gì với các URI?
Nó biết phải làm gì vì mọi resources hỗ trợ các interface giống nhau, cùng một tập hợp các phương pháp (hoặc các hoạt động. HTTP gọi những động từ này, và thêm vào hai động từ mọi người đều biết (GET và POST), tập hợp các phương pháp tiêu chuẩn bao gồm 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ề cách thực hiện của nó. Nếu bạn là một người lập trình hướng đối tượng, bạn có thể tưởng tượng rằng mọi resources trong một hệ thống RESTful HTTP mở rộng một class như thế này (trong một số Java / C #-cú pháp giả lập và tập trung vào các phương pháp chính):
class Resource {
Resource(URI u);
Response get();
Response post(Request r);
Response put(Request r);
Response delete();
}Bởi vì cùng một interface được sử dụng cho mọi resources, bạn có thể tin vào khả năng có thể truy vấn một đại điện - tức là , một vài biểu diễn của nó - sử dụng GET . Bởi vì ngữ nghĩa của GET được định nghĩa trong các đặc tả, bạn có thể chắc chắn rằng bạn không có nghĩa vụ phải mô tả lại - đây là lý do tại sao phương pháp này được gọi là "an toàn". GET hỗ trợ bộ nhớ đệm rất hiệu quả và tinh vi, vì vậy trong nhiều trường hợp, bạn thậm chí không cần phải gửi một yêu cầu đến máy chủ . Bạn cũng có thể chắc chắn rằng một GET là idempotent (Idempotent là thực hiện 10 requests và có chung 1 kết quả. 1 idempotent request có thể tạo ra 1 thứ gì đó trong cơ sở dữ liệu ở lần đầu tiên và không lặp lại hành động đó nữa - nếu bạn đưa ra một yêu cầu GET và không có kết quả , bạn có thể không biết yêu cầu của bạn không bao giờ tới địa điểm hoặc response đã bị mất trong lúc trả về. Bảo lãnh idempotence có nghĩa là bạn chỉ có thể phát lại yêu cầu.
Idempotence(danh từ của idempotent) cũng được bảo đảm cho PUT ( mà về cơ bản có nghĩa là " cập nhật resource này với dữ liệu này , hoặc tạo ra nó tại URI này nếu nó không có ở đó " ) và DELETE (bạn có thể chỉ cần cố gắng nhiều lần nữa cho đến khi bạn nhận được kết quả là - xóa cái gì mà không có ở đó không phải là một vấn đề) . POST , mà thường có nghĩa là " tạo ra một resource mới " , cũng có thể được sử dụng để khởi tạo tiến trình tùy ý và do đó hoặc là không an toàn hoặc là idempotent.
Nếu bạn đưa ra các chức năng ứng dụng của bạn (hoặc chức năng dịch vụ) trong một phương pháp RESTful,nguyên tắc này và hạn chế của nó áp dụng cho bạn là tốt. Điều này là khó chấp nhận nếu bạn đang sử dụng một phương pháp thiết kế khác - sau tất cả, bạn rất có thể bị thuyết phục rằng ứng dụng của bạn có logic nhiều hơn những gì có thể diễn tả với một số ít hoạt động. Hãy để tôi dành thời gian để cố gắng thuyết phục bạn rằng đây không phải là như thế.
Xem xét ví dụ sau đây của một scenario:
Bạn có thể thấy rằng có hai dịch vụ được khai báo ở đây (mà không ám chỉ bất kỳ công nghệ thực hiện cụ thể). Giao diện cho các dịch vụ này là riêng biệt cho từng task - đó là dịch vụ OrderManagement và CustomerManagement. Nếu một khách hàng muốn sử dụng các dịch vụ mà chúng ta đang bàn đến, nó cần phải được code dựa vào interface đặc biệt này - không có cách nào để dựa vào một client đã được sử dụng trước khi các interface này được đặc tả để tương tác một cách có ý nghĩa với chúng. Các interface xác định giao thức ứng dụng của dịch vụ.
Trong một cách tiếp cận RESTful HTTP, bạn sẽ nhận được interface chung tạo nên các giao thức ứng dụng HTTP. Bạn có thể đưa ra một cái gì đó như thế này:
Bạn có thể thấy những hoạt động cụ thể của một dịch vụ đã được map tới các phương thức HTTP tiêu chuẩn - và để phân biệt, tôi đã tạo ra một hệ thống resource đầy đủ mới. "Đó là 1 sự gian lận!". Một GET trên một URI xác định một khách hàng chỉ là có ý nghĩa như một hoạt động getCustomerDetails. Một số người đã sử dụng một hình tam giác để hình dung này:
Hãy tưởng tượng ba đỉnh là nút bạn có thể thay đổi. Bạn có thể thấy rằng, trong phương pháp tiếp cận đầu tiên, bạn có nhiều hoạt động và nhiều loại dữ liệu và một số cố định của "instances" (về cơ bản,nhiều như là các dịch vụ mà bạn có). Trong phương táp tiếp cận thứ 2, bạn có một số lượng giới hạn các hoạt động, nhiều loại dữ liệu và nhiều đối tượng để gọi các hàm đã được giới hạn trên. Vấn đề của việc này là để minh họa rằng về cơ bản bạn có thể thể hiện bất cứ điều gì bạn thích với cả hai phương pháp.
Tại sao điều này lại quan trọng ? Về cơ bản, nó làm cho phần ứng dụng của bạn trở thành 1 phần của web - đóng góp vào những gì đã biến Web vào ứng dụng thành công nhất của Internet là tỷ lệ thuận với số lượng resources mà nó thêm vào đó . Trong khi tiếp cận RESTful, một ứng dụng có thể thêm một vài triệu URI của khách hàng lên web , nếu nó được thiết kế theo cách giống như các ứng dụng trong CORBA(Common Object Request Broker Architecture) lần, đóng góp của nó thường là một "điểm cuối " duy nhất - — comparable to a very small door that provides entry to a universe of resource only for those who have the key.
Interface thống nhất cũng cho phép mọi thành phần mà hiểu được giao thức ứng dụng HTTP tương tác với các ứng dụng của bạn . Ví dụ về các thành phần được hưởng lợi từ điều này là ứng dụng chung phía client như proxy curl và wget, lưu trữ , máy chủ HTTP , gateways , ngay cả Google / Yahoo / MSN! , và nhiều hơn nữa.
Tóm tắt: Đối với khách hàng để có thể tương tác với các resources của bạn, họ cần thực hiện các giao thức ứng dụng mặc định ( HTTP ) một cách chính xác , tức là sử dụng các phương pháp tiêu chuẩn GET, PUT , POST , DELETE.
###4. Resources với nhiều cách biểu diễn
Chúng tôi đã bỏ qua một sự rắc rối nhẹ cho đến nay: làm thế nào để máy trạm biết làm cách nào để giải quyết những dữ liệu mà nó nhận được, ví dụ như là 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 tách biệt các mối quan tâm giữa tiếp nhận dữ liệu và gọi các hoạt động. Nói cách khác, một client mà biết làm thế nào để tiếp nhận một định dạng dữ liệu riêng biệt bât kỳ thì có thể tương tác với tất cả các resources, cái mà có thể cung cấp một đại diện trong định dạng này. Chúng ta hãy minh họa điều này bằng một ví dụ nữa. Sử dụng nội dung HTTP, một khách hàng có thể yêu cầu một sự thể hiện trong một định dạng đặc biệt:
GET /customers/1234 HTTP/1.1
Host: example.com
Accept: application/vnd.mycompany.customer+xml Kết quả có thể là 1 vài company-specific XML định dạng mà nó đại diện cho thông tin người dung. Nếu khách hàng gửi một yêu cầu khác tương tự như sau:
GET /customers/1234 HTTP/1.1
Host: example.com
Accept: text/x-vcard
Kết quả có thể là địa chỉ khách hàng trong định dạng VCard . (Tôi đã không đưa ra các responses, trong đó sẽ chứa siêu dữ liệu về các dữ liệu mô tả trong HTTP Content-type header). Điều này giải thích một cách ý tưởng rằng tại sao những thể hiện của một resource phải ở trong định dạng chuẩn - nếu một khách hàng "biết" giao thức HTTP và một tập hợp các định dạng dữ liệu , nó có thể tương tác với bất kỳ ứng dụng RESTful HTTP trên thế giới .
Thật không may, chúng ta không có định dạng chuẩn cho tất cả mọi thứ , nhưng bạn có thể hình dung như thế nào người ta có thể tạo ra một hệ sinh thái nhỏ hơn trong một công ty hay một tập hợp các đối tác cộng tác bằng cách dựa vào các định dạng tiêu chuẩn. Tất nhiên tất cả điều này không chỉ áp dụng cho các dữ liệu được gửi từ máy chủ cho máy trạm, mà còn cho các hướng ngược lại - một máy chủ có thể tiêu thụ dữ liệu trong các định dạng cụ thể mà không quan tâm đến các loại hình cụ thể của khách hàng, cung cấp nó theo giao thức ứng dụng .
Còn có một lợi ích quan trọng của việc có nhiều đại diện resource trong thực tế : Nếu bạn cung cấp một HTML và một biểu diễn XML của resource của bạn, họ có thể sử dụng không chỉ bởi ứng dụng của bạn , mà còn bởi tất cả các trình duyệt Web chuẩn - nói cách khác , thông tin trong ứng dụng của bạn trở nên có sẵn cho tất cả mọi người sử dụng web .
Có một cách khác để khai thác điều này: Bạn có thể chuyển ứng dụng giao diện người dùng Web thành Web API của nó - sau khi tất cả , thiết kế API thường được thúc đẩy bởi ý tưởng rằng tất cả mọi thứ có thể được thực hiện thông qua giao diện người dùng, cái mà nên có thể thực hiện được thông qua API. Gộp hai nhiệm vụ vào một là một cách khá hữu ích để có được một giao diện web tốt hơn cho cả con người và các ứng dụng khác.
Tóm tắt: Cung cấp nhiều đại diện của resources cho các nhu cầu khác nhau.
###5. Giao tiếp statelessly (Communicate statelessly)
Nguyên tắc cuối cùng tôi muốn chỉ ra là stateless communication. Trước hết, cần nhấn mạnh rằng mặc dù REST bao gồm các ý tưởng của statelessness , nhưng đ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ế, nếu ứng dụng không có state thì mọi trao đổi từ đầu đến bây giờ đểu trở nên vô ích. REST ám chỉ rằng state hoặc là được chuyển về resource state, hoặc lưu giữ trên máy trạm. 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 state giao chobất kỳ khách hàng nào mà nó giao tiếp bên ngoài một request đơn. Lý do rõ ràng nhất cho điều này là khả năng mở rộng - số lượng khách hàng tương tác sẽ ảnh hưởng nghiêm trọng tới server’s footprint nếu nó phải giữ state của máy trạm. (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à đính một URI tới một session state nào đó 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: Statelessness phân lập ràng buộc các máy trạm chống lại những thay đổi trên máy chủ vì nó không phụ thuộc vào sự nói chuyện với cùng một máy chủ trong hai yêu cầu liên tiếp . Một máy trạm 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ố quá trình, máy chủ có thể được tắt, đĩ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 máy trạm đi theo một trong các liên kết đã nhận được từ máy chủ , nó sẽ không nhận biết được
##REST trong lý thuyết
Tôi có một lời thú nhận: Những gì tôi đã giải thích không thực sự là REST, và tôi có thể nhận được phản ứng không tốt vì đơn giản hóa quá nhiều. Nhưng tôi muốn có 1 sự bắt đầukhác một chút so với bình thường, vì vậy tôi đã không cung cấp nền tảng chính thức và lịch sử của REST ở đầu bài viết. Hãy để tôi cố gắng giải quyết vấn đề này, nếu có phần nào đó quá tóm tắt.
Đầu tiên, tôi sẽ tránh nói về sự quan tâm đến việc phân biệt REST từ chính HTTP và việc sử dụng HTTP trong phương pháp RESTful. Để hiểu mối quan hệ giữa những khía cạnh này, chúng ta cần phải để ý tới lịch sử của REST.
Khái niệm REST được định nghĩa bởi Roy T.Fielding trong đồ án tốt nghiệp PhD của ông. Roy đã là một trong những nhà thiết kế chính của nhiều giao thức web, bao gồm cả HTTP và URI, và ông chuẩn hóa hóa rất nhiều ý tưởng khi chúng đang còn trên giấy. (Luận án được coi là "kinh thánh về REST", và đúng là như vậy -. Sau tất cả, tác giả phát minh ra thuật ngữ, vì vậy theo định nghĩa, bất cứ điều gì ông đã viết về nó phải được xem xét).
Trong luận án, đầu tiên Roy xác định một phương pháp để nói chuyện về kiểu kiến trúc cấp cao, abstract patterns biểu thị những ý tưởng cơ bản đằng sau một cách tiếp cận về kiến trúc. Mỗi kiểu trúc đi kèm với một tập các ràng buộc để xác định nó. Ví dụ về các phong cách kiến trúc bao gồm các "null style" (mà không có hạn chế ở tất cả), pipe và các bộ lọc, khách hàng / máy chủ, các đối tượng phân phối và - bạn đoán ra nó – REST.
Nếu tất cả những thứ này khá trừu tượng đối với bạn, tức là bạn đã đúng - REST trong chính nó là một phong cách cao cấp có thể được thực hiện sử dụng nhiều công nghệ khác nhau, và khởi tạo giá trị sử dụng khác nhau cho các thuộc tính trừu tượng của nó. Ví dụ, REST bao gồm các khái niệm về resource và một interface thống nhất - ví dụ ý tưởng là mọi resources nên response lại với các method giống nhau. Nhưng REST không nói những method nào và có bao nhiêu method.
Một "hóa thân" của phong cách REST là HTTP (và một tập hợp các thiết lập liên quan đến các tiêu chuẩn, chẳng hạn như URI), hoặc hơi trừu tượng hơn: kiến trúc của web. Tiếp tục ví dụ trên, HTTP "khởi tạo" các interface thống nhất REST với một điều đặc biệt, bao gồm các động từ(GET, POST...) của HTTP. Như Roy đã xác định kiểu REST sau Web - hoặc ít nhất, hầu hết là đã được "thực hiện", one might argue whether it’s a 100% match. Nhưng trong bất kỳ trường hợp nào, trên web, HTTP và URI là chủ yếu, chắc chắn là có trường hợp nào đó có liên quan đến toàn bộ phương pháp REST. Và như Roy Fielding là cả tác giả của luận án REST và đã có một ảnh hưởng mạnh mẽ về thiết kế kiến trúc web, điều này không đến một cách bất ngờ.
Cuối cùng, đôi lúc tôi đã sử dụng thuật ngữ "RESTful HTTP", vì một lý do đơn giản: Nhiều ứng dụng sử dụng HTTP không tuân theo các nguyên tắc của REST - và với một số lời ngụy biện, có thể nói rằng việc sử dụng HTTP mà không tuân theo các nguyên tắc REST là lạm dụng HTTP. Tất nhiên điều này có vẻ một chút sôt sắng - và trong thực tế thường có những lý do tại sao người ta sẽ vi phạm vào ràng buộc REST, chỉ đơn giản bởi vì mỗi ràng buộc gây ra gây ra một vài sự thỏa hiệp có thể không được chấp nhận trong một số tình huống cụ thể. Nhưng thông thường, ràng buộc REST bị vi phạm do một sự thiếu hiểu biết nhỏ về lợi ích của nó.
Để cung cấp một ví dụ đặc biệt: việc sử dụng HTTP GET để gọi các hoạt động như xóa một đối tượng vi phạm hạn chế an toàn của REST và plain common sense (khách hàng không thể chịu trách nhiệm, mà có lẽ không phải những gì các nhà phát triển máy chủ dự định).
Nhưng hơn hết, những sự lạm dụng khác, sẽ viết trong một bài viết tiếp theo.
(Đoạn này thực sự là tác giả viết rất khó dịch, nên tôi khuyên các bạn nên tham chiếu đến bản gốc.)
##Summary
Trong bài biết này, tôi đã cố gắng cung cấp 1 bài giới thiệu nhanh về những khái niệm đằng sau REST, kiến trúc của Web. 1 sự tiếp cận RESTful HTTP để lộ chức năng khác với RPC, Distributed Objects, và các dịch vụ Web.
Sẽ phải có một số thay đổi trong ý nghĩ để thực sự hiểu được sự khác biệt này. Nhận thức về các nguyên tắc REST là mang lại lợi ích cho dù bạn đang xây dựng các ứng dụng tiếp xúc với một giao diện người dùng web hoặc chỉ muốn chuyển ứng dụng API của bạn.
##References
http://www.infoq.com/articles/rest-introduction
http://blog.brush.co.nz/2008/03/more-get-post/