Looking for clear and concise explanations of this concept.
Nothing wrong with an answer... unless you expect people to start pasting text from Wikipedia. +1
moose-in-the-jungle
2009-02-16 00:58:19
+1
A:
It means using names to identify both commands and parameters.
Instead of names being mere handles or monikers, the name itself contains information. Specifically, information about what is being requested, parameters for the request, etc..
Names are not "roots" but rather actions plus input data.
Jason Cohen
2009-02-16 00:47:39
+11
A:
Ryan Tomayko wrote a good article called How I Explained REST to My Wife that I always point people to as a good introduction to the concept.
Bill the Lizard
2009-02-16 01:08:35
+15
A:
A RESTful application is an application that exposes its state and functionality as a set of resources that the clients can manipulate and conforms to a certain set of principles:
- All resources are uniquely addressable, usually through URIs; other addressing can also be used, though.
- All resources can be manipulated through a constrained set of well-known actions, usually CRUD (create, read, update, delete), represented most often through the HTTP's POST, GET, PUT and DELETE; it can be a different set or a subset though - for example, some implementations limit that set to read and modify only (GET and PUT) for example
- The data for all resources is transferred through any of a constrained number of well-known representations, usually HTML, XML or JSON;
- The communication between the client and the application is performed over a stateless protocol that allows for multiple layered intermediaries that can reroute and cache the requests and response packets transparently for the client and the application.
The Wikipedia article pointed by Tim Scott gives more details about the origin of REST, detailed principles, examples and so on.
Franci Penov
2009-02-16 01:09:01
Unfortunately, inferring that CRUD maps to GET,PUT, POST, DELETE is extremely misleading when trying understand REST. The next question is always, "yet but what if I have to do other operations". As you mention in a later comment, PUT can create and as I explain, POST may not Create. Forget CRUD!
Darrel Miller
2009-02-16 14:53:31
XML and Json are horrible media types to use in REST. The only scenario where they really work is when doing AJAX in a browser where you are downloading Java script that understands the format of the XML/JSON. In other scenarios you need to use a more semantically meaningful data type.
Darrel Miller
2009-02-16 14:55:59
@Darell - Both XML and JSON are two of the most widely used resource representation formats, so they should be mentioned, irrespective of whether they are the best ones. Same applies to CRUP and its HTTP verbs mapping.
Franci Penov
2009-02-16 15:31:44
@Darell - I happen to agree with you on JSON. I am not sure why you consider XML to be horrible representation (not media) of the resource data and what would be a more semantically meaningfull data type for machine consumption.
Franci Penov
2009-02-16 15:33:08
If you return an application/atom+xml doc, I know what <feed> and <entry> elements are. If you return an application/xml document I know nothing other than it contains elements and attributes. Any additional interpretation of the xml document introduces client/server coupling
Darrel Miller
2009-02-16 19:30:18
@darrel - you don't have any clue what the data inside the atom entry is. for example, if the REST API returns a list of stock quotes, atom would be good container, but you need the client to be able to understand the data points like open, close, volume, bid, ask and so on.
Franci Penov
2009-02-16 19:52:17
@Franci Read Roy's fourth point here... http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Darrel Miller
2009-02-17 00:37:17
@Franci You are right about atom not specifying anything about stock quotes. That's why feed aggregators don't track your portfolios.
Darrel Miller
2009-02-17 00:40:44
@Darrel - I'd be interested to hear how you would design a REST API that manipulates a set of users and their friend relationship and in particular what representation you would choose for each resource. We should take this over email though; comments here are too short for a good discussion. :-)
Franci Penov
2009-02-17 01:27:34
+3
A:
Frankly, the answer depends on context. REST and RESTful have meanings depending on what language or framework you're using or what you're trying to accomplish. Since you've tagged your question under "web services" I'll answer in the context of RESTful web services, which is still a broad category.
RESTful web services can mean anything from a strict REST interpretation, where all actions are done in a strict "RESTful" manner, to a protocol that is plain XML, meaning its not SOAP or XMLRPC. In the latter case, this is a misnomer: such a REST protocol is really a "plain old XML" (or "POX") protocol. While REST protocols usually use XML and as such are POX protocols, this doesn't necessarily have to be the case, and the inverse is not true (a just because a protocol uses XML doesn't make it RESTful).
Without further ado, a truly RESTful API consists of actions taken on objects, represented by the HTTP method used and the URL of that object. The actions are about the data and not about what the method does. For example, CRUD actions (create, read, update, and delete) can map to a certain set of URLs and actions. Lets say you are interacting with a photo API.
- To create a photo, you'd send data via a POST request to /photos. It would let you know where the photo is via the Location header, e.g. /photos/12345
- To view a photo, you'd use GET /photos/12345
- To update a photo, you'd send data via a PUT request to /photos/12345.
- To delete a photo, you'd use DELETE /photos/12345
- To get a list of photos, you'd use GET /photos.
Other actions might be implemented, like the ability to copy photos via a COPY request.
In this way, the HTTP method you're using maps directly to the intent of your call, instead of sending the action you wish to take as part of the API. To contrast, a non-RESTful API might use many more URLs and only use the GET and POST actions. So, in this example, you might see:
- To create a photo, send a POST to /photos/create
- To view a photo, send a GET to /photos/view/12345
- To update a photo, send a POST to /photos/update/12345
- To delete a photo, send a GET to /photos/delete/12345
- To get a list of photos, send a GET to /photos/list
You'll note how in this case the URLs are different and the methods are chosen only out of technical necessity: to send data, you must use a POST, while all other requests use GET.
wuputah
2009-02-16 01:13:13
actually, POST is used to represent Create and PUT to Update. however, since some server implementations don't support PUT natively, POST is overloaded for both operations.
Franci Penov
2009-02-16 01:19:39
Sorry, there's no debate. :-) RFC 2616 specifies exactly the operations for POST and PUT. Paragraph 2.5, POST method requests the enclosed entity to be accepted as a new subordinate of the requested URL. Pargraph 2.6, PUT method requests the enclosed entity to be stored at the specified URL.
Franci Penov
2009-02-16 02:02:35
There are subtle details of that behavior, for example PUT can be used to create new resource. However, POST should never put the new entity at the request URL and PUT should always put any new entity at the request URL. This relationship to the request URL defines POST as CREATE and PUT as UPDATE.
Franci Penov
2009-02-16 02:05:56
For more details, here's the link to RFC 2616 Hypertext Transfer Protocol (HTTP1.1) - http://tools.ietf.org/html/rfc2616
Franci Penov
2009-02-16 02:07:11
You're right, I did get them swapped around. Additionally, the Amazon S3 API makes for a pretty bad REST example, which is what I was looking at the time. ;)
wuputah
2009-02-16 02:19:56
@franci You only partially quoted RFC 2616. It also says POST "Providing a block of data, such as the result of submitting a form, to a data-handling process" and "action performed by the POST method might not result in a resource that can be identified by a URI" POST is not limited to Create
Darrel Miller
2009-02-16 14:48:54
@Darrel POST might not create new resource, but if it does, the new resource can't be at the request URL. thus, POST should not be used as Update for REST. Unfortunately, the form data functionality overload is what messes up things.
Franci Penov
2009-02-16 15:26:51
+3
A:
Just a few points:
- RESTFul doesn't depend on the framework you use. It depends on the architectural style it describes. If you don't follow the constraints, you're not RESTful. The constraints are defined in half a page of Chapter 5 of Roy Fielding's document, I encourage you to go and read it.
- The identifier is opaque and does not cary any information beyond the identification of a resource. It's a nmae, not input data, just names. as far as the client is concerned, it has no logic or value beyond knowing how to build querystrings from a form tag. If your client builds its own URIs using a schema you've decided up-front, you're not restful.
- The use or not use of all the http verbs is not really the constraint, and it's perfectly acceptable to design an architecture that only supports POST.
- Caching, high decoupling, lack of session state and layered architecture are the points few talk about but the most important to the success of a RESTful architecture.
If you don't spend most of your time crafting your document format, you're probably not doing REST.
serialseb
2009-02-16 06:41:22
+1
A:
I've learned the most from reading the articles published on InfoQ.com: http://www.infoq.com/rest and the RESTful Web Services book (http://oreilly.com/catalog/9780596529260/).
./alex
Disclaimer: I am associated with InfoQ.com, but this recommendation is based on my own learning experience.
alexpopescu
2009-02-21 11:21:01
A:
RESTful - Being able to find and fix that #@$%# error that you can't fugure out at 3am so you can go to bed and get at least 3hours of sleep before you find another problem
];o)
J/K (sort of)
Tim
2009-02-24 19:34:46
A:
REST by way of an example:
POST /user
fname=John&lname=Doe&age=25
The server responds:
200 OK
Location: /user/123
In the future, you can then retrieve the user information:
GET /user/123
The server responds:
200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>
To update:
PUT /user/123
fname=Johnny
pbreitenbach
2009-07-04 07:22:01