Thursday, June 22, 2006
EJAX: what is REST
The architectural philophy behind EJAX is to use the web as it was designed. It is therefore based upon REST. As Roy Fielding, the author of the HTTP specification writes in his dissertation:
REST stands for Representation State Transfer. It argues that the web is a collection of resources upon one operates with verbs. Resources are for example products or customers. There's an endless list of them. Resources are usually, but not necessarily, things. Resources can be accessed by one or more URLs.
The verbs are much more limited: there are only four. GET to retrieve a representation of a resource, POST to create a new resource, PUT to update a resource and DELETE to delete a resource.
To give an example, we could have a resource called customer and make it available through the following URLs:
The World Wide Web is arguably the world's largest distributed application. Understanding the key architectural principles underlying the Web can help explain its technical success and may lead to improvements in other distributed applications, particularly those that are amenable to the same or similar methods of interaction. REST contributes both the rationale behind the modern Web's software architecture and a significant lesson in how software engineering principles can be systematically applied in the design and evaluation of a real software system.So if REST is what the web is meant to be, we should surely follow its core principles to work with the web instead of fighting it. Approaches like SOAP are perhaps useful to get stuff through a firewall, but they fight the architectural underpinnings of web instead of working with it.
REST stands for Representation State Transfer. It argues that the web is a collection of resources upon one operates with verbs. Resources are for example products or customers. There's an endless list of them. Resources are usually, but not necessarily, things. Resources can be accessed by one or more URLs.
The verbs are much more limited: there are only four. GET to retrieve a representation of a resource, POST to create a new resource, PUT to update a resource and DELETE to delete a resource.
To give an example, we could have a resource called customer and make it available through the following URLs:
- a GET on /customers/ returns a representation, for example an HTML table, of all customers.
- a POST to /customers/ creates a new customer.
- a GET on /customers/40 retrieves customer number 40.
- a POST to /customers/40 updates customer number 40.
- a DELETE on /customers/40 deletes customer number 40.
Comments:
<< Home
Thank you Berend, I did not know this concept. Data comes back into focus... Mmm, interesting. Maybe I'll include that in ESE.
Cheers
Cyril
Cheers
Cyril
And for a really simple introduction:
"How I explained REST to my wife":
http://naeblis.cx/rtomayko/2004/12/12/rest-to-my-wife
Post a Comment
"How I explained REST to my wife":
http://naeblis.cx/rtomayko/2004/12/12/rest-to-my-wife
<< Home