##SƠ LƯỢC VỀ REST Bạn có thể biết hoặc không biết được rằng có một cuộc tranh luận đang xảy ra về một phương pháp chính xác để thực hiện về việc giao tiếp không đồng nhất giữa các ứng dụng: Trong khi xu hướng tập chung vào web services dựa vào SOAP, WSDL và toàn bộ WS-*, Trong tình hình hiện nay co một bộ phận nhỏ đã đưa ra được một phương pháp tốt hơn đó là: REST (Representation State Stranfer). Trong bài viết này, tôi sẽ giới thiều về ứng dụng tương tác REST và RESTful HTTP mà không làm ảnh hưởng tới cuộc tranh luận. Tôi sẽ đi vào chi tiết hơn trong khi giải thích các khía cạnh bằng kinh nghiệm của tôi.
##KEY REST PRINCIPLES
Hầu hết các bài giới thiệu về REST đều bắt đầu theo kiểu định nghĩa và cơ bản, tôi sẽ không đề cập đến việc này trong một thời gian và cung cấp một số một số điều đơn giản, định nghĩa một cách thực tế: REST là một tập các qui tắc, định nghĩa chuẩn Web như HTTP và URI để sử dụng (thường khác một chút so với những gì nhiều người thực sự làm). Nếu bạn sử dụng REST trong quá trình thiết kế ứng dụng của bạn, bạn sẽ kết thúc với một hệ thống kiến trúc web với nhiều lợi thế. Có 5 quy tắc là
- Để mỗi “thing” là ID
- Liên kết mọi thứ cùng nhau
- 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)
##ĐỂ MỖI "thing" LÀ MỘT ID
Tôi sử dụng thuật ngữ “thing” ở đây thay vì “resource” là vì nó là quy tắc đơn giản không nên ẩn sau các từ chuyên môn. Nếu bạn nghĩ về hệ thống mà người xây dựng, có sử dụng một tập các khóa trừu tượng. 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).
Lợi ích chính hệ thống đặt tên cho “thing” là bạn không cần đến cấu trúc của bạn, bạn có thể dựa trên những cái đã được định nghĩa sẵn. Nếu bạn xem một đối tượng bất kỳ ở mức high-level trong ứng dụng cuối cùng mà bạn đã xây dựng (Giả định nó không được xây dựng theo kiểu RESTful), nó có thể có rất nhiều sự lựa chọn ở đó bạn sẽ có lợi từ việc sử dụng chúng. Nếu như ứng dụng của bạn có một Customer abtract, một instance, tôi chắc chắn rằng người dùng có thể thích gửi link tới một customer thông qua email từ một co-worker, tạo ra một bookmark cho trình duyệt hoặc thậm chí là viết xuống một mảnh giấy. Hãy tưởng tượng rằng thật kinh khủng nếu của hàng trực tuyến amazon.com không định danh mỗi sản phẩm là một id duy nhất (một URI).
Khi phải đối mặt với ý tưởng này, nhiều người tự hỏi liệu điều này có nghĩa là họ nên đưa ra với các mục cơ sở dữ liệu của họ một cách trực tiếp (hoặc id của chúng) và thật kinh hoàng vì đây mới chỉ là ý tưởng, từ nhiều năm làm việc 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à một yêu cầu cài đặt chi tiết. Nhưng không có sự xung đột: things – resources nó được định danh bằng URI trừu tượng hơn nhiều so với toàn bộ database. Ví dụ một Order resource có thể có rất nhiều các order item, và một địa chỉ và nhiều khía cạnh khác mà bạn có thể không muốn để lộ resource mang tính cá nhân.
Lấy ý tưởng của việc xác định tất cả mọi thứ đáng được định danh để tiếp tục dẫn đến việc tạo ra các resources mà bạn thường không nhìn thấy trong thiết kế ứng dụng thông thường: một process or một bước của process, một request báo giá ... tất cả những ví dụ của “things” được định danh. có thể dẫn đến việc tạo ra các thực thể bền vững hơn trong một thiết kế không RESTful.
Dưới đây là một số ví dụ cho 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 Tôi chọn cách mà còn người có thể đọc được URI - một khái niệm hữu ích, thậm chí nó không phải là điều kiện tiên quyết cho việc thiết kế RESTful. Nó khá là dễ để hiểu. hãy nhìn vào bên dưới :
Related Vendor Content
API Patterns for Cloud & Mobile
Mobile Middleware Buyer`s Guide
Behind the Scenes of a Mobile App
451 Group Analyst Report: Review of Intel & Mashery API Management Platform
API Management - Application Security Made Easy
Related Sponsor
*Video: Amazon Web Services Security Overview
*Video: Scaling APIs across Multiple properties
http://example.com/orders/2007/11
http://example.com/products?color=greenĐầu tiên, sự xuất hiện này có một vài điều khác nhau, chúng không định danh một "thing", nhưng một collection của things (giả định URI đầu tiên xác định tất cả các đơn đặt hàng gửi vào tháng 11 năm 2007, và URI thứ hai một trong những bộ sản phẩm màu xanh lá cây). Nhưng những collentions thing - resource - bản thân chúng, và chúng nên định danh một cách dễ dàng.
Lưu ý rằng những lợi ích của việc duy nhất, sơ đồ hệ thống đặt tên toàn cục á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ới máy machine-to-machine.
Tổng kết những nguyên tắc đầu tiên: Sử dụng URI để định danh cho mọi thứ đang ra có thể được định danh, một cách cụ thể, tất cả các resource "high-level" mà ứng dụng của bạn cung cấp, cho dù chúng đại diện cho các cá nhân, tập các mặt hàng, các đối tượng ảo và vật lý, hoặc tính toán kết quả.
##LINK THINGS TOGETHER
Nguyên tắc tiếp theo chúng ta sẽ nhìn vào một cách miêu tả hơi khó một chút: "Hypermedia as the engine of application state", đôi khi được viết tắt là HATEOAS. Tại cốt lõi của nó là khái niệm về hypermedia, hay nói cách khác: các ý tưởng của các liên kết. Liên kết là một cái gì đó chúng ta đều quen thuộc với từ HTML, nhưng chúng không giới hạn người dùng. Xem xét các hư cấu đoạn XML sau đây:
<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 đã truy vấn nó có thể "theo" các liên kết để truy vấn 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ừ một hệ thống đặt tên ứng dụng cụ thể, nhưng chỉ trong ngữ 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 khác, một server khác, hoặc thậm chí một công ty trên lục địa khác - bởi vì các hệ thống đặ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 ứng dụng sang một “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ớm, 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 thing (resource) bất cứ nơi nào có thể. Hyperlinking là những gì làm cho các trang web.
##SỬ DỤNG CÁC PHƯƠNG THỨC CHUẨN
Có một giả định ngầm trong các cuộc thảo luận của hai 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, bạn có thể nhập vào trường địa chỉ của trình duyệt và nhấn trở lại - 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 resource hỗ trợ các interface giống nhau, cùng một tập hợp các phương thức(hoặc các hành động)
HTTP gọi những verb, và thêm vào hai method mọi người đều biết (GET và POST), tập hợp các method 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ề hành vi của chúng. Nếu bạn là một nhà phát triển hướng đối tượng, bạn có thể tưởng tượng rằng mọi resource trong một HTTP mở rộng một lớp học như thế này (trong một số Java / C #-phong cách giả cú pháp và tập trung vào các method hí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 resource, bạn có thể tin vào khả năng có thể truy vấn một đại điện (representation) - tức là đôi khi bạn muốn render nó bạ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ần phải mô tả lại - đây là lý do tại sao phương pháp này được gọi là "safe". 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 - nếu bạn đưa ra một request GET và không có kết quả, bạn có thể không biết request của bạn không bao giờ tới địa điểm hoặc respond đã bị mất trên đường trở về với bạn. Sự bảo đảm idempotence có nghĩa là bạn chỉ có thể gửi lại request.
Idempotence cũng được bảo đảm cho PUT (mà về cơ bản có nghĩa là "cập nhật resouce 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 tồn tại") và DELETE (bạn có thể chỉ cần cố gắng một lần nữa và một lần nữa cho đến khi bạn nhận được kết quả là - xóa cái gì mà mà không có lỗi). POST, thường có nghĩa là tạo một "resource" mới, cũng có thể được sử dụng để gọi xử lý tùy chọn và do đó không phải là "safe" cũng không idempotent.
Nếu bạn cung cấp các chức năng ứng dụng của bạn (hoặc chức năng dịch vụ) theo 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, 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 như thế.
Xem xét ví dụ sau đây 0của một kịch bản mua sắm đơn giản:
Bạn có thể thấy rằng có hai dịch vụ được xác định ở đâ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à cụ thể cho từng công việc - đó là một dịch vụ OrderManagement và CustomerManagement. Nếu một khách hàng muốn sử dụng các dịch vụ này, nó cần phải được code dựa giao diện đặc biệt này - không có cách nào để sử dụng một client mà đã được xây dựng trước khi các giao diện đã được đặc tả để có ý nghĩa tương tác với họ. Các giao diện 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 bởi với các giao diện chung tạo nên các HTTP application protocol. Bạn có thể đưa ra một cái gì đó như thế này:
Hãy tưởng tượng ba đỉnh là nút bạn có thể xoay. Bạn có thể thấy trong các 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 "instance" (về cơ bản, như nhiều các dịch vụ). Trong phương pháp tiếp cận thứ 2, bạn có một số hữu hạn các hoạt động, nhiều loại dữ liệu và các đối tượng để gọi các phương thức cố định trên. Mục tiêu 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 tiếp cận.
Tại sao điều này quan trọng? Về cơ bản, nó làm cho phần ứng dụng của bạn trở thành trang 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 tài nguyên mà nó thêm vào đó. Trong một cách tiếp cận resource, một ứng dụng có thể thêm một vài triệu URI client lên web, nếu nó được thiết kế các ứng dụng cùng một cách đã được thiết kế trong CORBA(Common Object Request Broker Architecture) lần, đóng góp của nó thường là một "endpoint" duy nhất - so sánh với một cánh cửa rất nhỏ cung cấp nhập cảnh vào một tài nguyên duy nhất cho những người có chìa khóa.
Giao diện 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 phía client trung gian như proxy curl và wget,getways, máy chủ HTTP, ngay cả Google / Yahoo / MSN!...
Tóm tắt: Đối với khách hàng để có thể tương tác với các resource 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.
##Resources with multiple representations
Chúng tôi đã bỏ qua một rắc rối nhỏ cho đến nay: 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ư 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 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. 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 client có thể yêu cầu một representation 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ể có một số định dạng company-specific XML cho thông tin khách hàng. Nếu khách hàng gửi một yêu cầu khác nhau, ví dụ một như thế này:
GET /customers/1234 HTTP/1.1
Host: example.com
Accept: text/x-vcard Kết quả có thể là địa chỉ client trong định dạng VCard. (Tôi đã không đưa ra các responses, trong đó sẽ metadata về các loại dữ liệu trong HTTP Content-type header) Điều này cho thấy lý do tại sao lý tưởng, các thể hiện của resource phải ở trong resource trong định dạng tiêu chuẩn - nếu một client "biết" cả hai 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 một cách rất có ý nghĩa.
Thật không may, chúng ta không có định dạng tiêu 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ừ sevver cho client 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ể không quan tâm đến các loại hình cụ thể của client, 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 của resource trong thực tế: Nếu bạn cung cấp cả một HTML và một đại diện XML của resource của bạn, chúng 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ông khai cho tất cả mọi người biết cách sử dụng web.
Có một cách khác để khai thác điều này: Bạn có thể thay đổi ứng dụng giao diện người dùng Web vào Web API của nó, 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ũng 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 các nguồn tài nguyên cho các nhu cầu khác nhau.
##COMMUNICATE STATELESSLY
Nguyên tắc cuối cùng tôi muốn giải quyết vấn đề 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.
##REST IN THEORY
Tôi có một lời thú nhận: Những gì tôi đã giải thích là không thực sự REST, và tôi có thể nhận được phản ứng không tốt cho đơn giản hóa quá nhiều. Nhưng tôi muốn bắt đầu việc khá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 và lịch sử của REST trong đầu bài viết.
Trước hết, tôi đã hết sức trành nói về REST từ bản thân HTTP và việc sử dụng HTTP một cách RESTful. Để hiểu được mối quan hệ giữa các khía cạnh khác nhau, chúng ta phải có một cái nhìn vào lịch sử của REST.
REST được định nghĩa bởi Roy T.Fielding trong PhD thesis của ông ấy. Roy đã là một trong những nhà thiết kế chính của nhiều giao thức web cần thiết, bao gồm cả HTTP và URI, và ông chuẩn hóa rất nhiều ý tưởng khi chúng còn đang trên giấy. (Luận án được coi là "the REST bible", và đúng là như vậy - sau khi 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 bản quyền).
Trong luận án, Roy đầu tiên xác định một phương pháp luận để nói về architectural styles — high-level, mô hình trừu tượng thể hiện những ý tưởng cốt lõi đằng sau một cách tiếp cận kiến trúc. Mỗi phong cách kiến 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ế), pipe và các bộ lọc, client/server, các đối tượng phân tán bạn đoán nó – REST.
Nếu tất cả những thứ này khá trừu tượng đối với bạn, bạn có quyền - REST trong chính nó là một hight-level styles 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ị 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 giao diện thống nhất - tức là ý tưởng rằng mọi resource cần đáp ứng các phương thức tương tự. Nhưng yên không nói trước với các phương pháp này có thể, hoặc có bao nhiêu người trong số chúng có thể.
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 trừu tượng hơn: "the Web’s architecture itself". Tiếp tục ví dụ trên, HTTP "khởi tạo" các giao diện thống nhất REST với một đặc biệt, bao gồm các động từ HTTP. Như Fielding xác định phong cách REST sau Web - hoặc ít nhất, hầu hết - đã được "thực hiện", người ta có thể tranh luận cho dù đó là phù hợp 100%. Nhưng trong mọi trường hợp, các trang web, HTTP và URI là chủ yếu, chắc chắn là trường hợp duy nhất có liên quan hoàn toàn đến phong cách 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.
Cuối cùng, tôi đã sử dụng thuật ngữ "RESTful HTTP" theo thời gian, 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ố biện minh, có thể nói rằng việc sử dụng HTTP mà không 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 một ràng buộc REST, đơn giản chỉ vì mỗi ràng buộc gây ra một số một vài sự thỏa hiệp có thể không được chấp nhận trong một tình huống cụ thể. Nhưng thường xuyên, REST constraints bị vi phạm do thiếu sự hiểu biết của họ. Để cung cấp một ví dụ đặc biệt khó chịu: 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 chế an toàn REST và ý thức đơn giản (client 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 nữa, sự lạm dụng đáng chú ý khác, trong một bài viết tiếp theo.
##Summary
Trong bài viết này, tôi đã cố gắng để cung cấp một giới thiệu nhanh chóng vào các khái niệm đằng sau REST, kiến trúc của trang web. Một cách tiếp cận RESTful HTTP để trình bày chức năng khác với RPC, các đối tượng phân tán, và các dịch vụ Web; nó có một số thay đổi tâm trí để 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 bạn dù bạn đang xây dựng các ứng dụng trình bày với một giao diện người dùng web.
##REFERENCES http://www.infoq.com/articles/rest-introduction