The Design of Software

What exactly is REST (or REST-ful) API and what is the history behind it? Where did it originate?
All I can figure out is that it is just URLs that usually return XML in some particular format like RSS or something.
Is this all there is to know about it?
I couldnt find any "definitive guide/specs" through google.

"Is this all there is to know about it?"

Yup.

REST is the model of the Web.  For example, your browser makes a request to a URL and receives a response.  That request can be a GET or POST (or a PUT, DELETE, or HEAD) and the response can be anything -- HTML, an image file, a PDF, XML.

The point is that anything, no just a browser, can make that sort of request and process the response.  And thus, you have REST.

http://discuss.joelonsoftware.com/default.asp?joel.3.38167

How does it differ from http?

http is a data transfer protocol. rest is a style of handling resources. http happens to work nicely with rest, but is also often used in different styles. the thread i linked above has a bunch of links to good resources.

To clarify what mb said..  REST runs on top of HTTP.

You could start with Ray Fielding's dissertation, where he coined the term "REST" and defined the style. You want history, this is it:
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

A good example of a well-documented REST interface is Flickr's. Browse around here for some good implementations of the convention:
http://www.flickr.com/services/api/

The web framework Ruby on Rails considers REST so important that it essentially forces (encourages?) you to build in a RESTful style. IOW, it does all the URL rewriting and parsing for you:
http://www.rubyonrails.org

It's true that Fielding didn't "invent" REST, he only formally described it and the benefits of using it. REST is, sorta, the "model of the web" as someone wrote above. It seems incomplete though to simply say: it's the way browsers work via GET or POST. Typically, REST means "directory-structure-like URLS used as parameterized calls to backend methods." This works very nicely in many cases, where you want to call something like:
foo.cgi?o=someObject&m=someMethod&p=someID

which can be nicely rewritten as:
foo.cgi/someObject/someMethod/someID

Typically, you'll get XML back when you call a REST API. Although there's no reqirement to do so.

Good links Andrew. Thanks for that.
So does it mean that if my url is of the type foo.cgi?o=someObject&m=someMethod&p=someID it is NOT RESTful?

Because in the case I am considering to open using REST, it may not be possible to do away with the parameters.

Be careful, there is a lot of incorrect stuff here. HTTP is not a data transfer protocol, it is an application protocol (or a coordination language, if you swing that way). REST does not "run on top of HTTP" but rather HTTP is a protocol that displays many of the traits of the REST architectural style. Most REST services in deployment do not return XML, most return HTML. REST has no preference for XML. Finally, there is no difference (from REST's point of view) between the slash based URI and the parameter based URI reference above.

I guess I /could/ try to be helpful too ...

Try the rest-discuss ( http://dir.gmane.org/gmane.comp.web.services.rest ) yahoo group. Good signal:noise, very newbie tolerant.

Paul Prescod's site is where I originally found the religion: http://www.prescod.net .

Mark Baker is a leader in the community with a blog: http://markbaker.ca/2002/09/Blog/ .

Let me ammend my previous comment to acknowledge that there are sound technical reasons to prefer the slash URI over the parameter URI, but that from a pure (academic) REST perspective, they are equally acceptable.

Oh, and it's Roy, not Ray. :-P

In response to Andrew, Roy did in fact invent REST.  In addition, the description of a call as "foo.cgi/someObject/someMethod/someID", respectfully, totally misses the point.  The point is to get stuff done using only REST's uniform interface; semantics akin to HTTP's methods, ala GET, PUT, POST, DELETE, ...  A good litmus test for RESTfulness, at least in this respect, is that your URIs should only contain nouns.  e.g. http://example.org/architecture/styles/rest/uniform-interface

P.S. Matt, HTTP is a data transfer protocol.

Is there an authoritative definition somewhere to delineate between transfer and transport? I understand the difference but fear the people parse them as equivalent terms. That's why I always push people to say Application.

I hear ya, Matt.  Nope, nothing authoritative AFAIK, except for perhaps the IETF RFC series which defines them implicitly through years of developing both kinds of protocols.

If an analogy would help, transport could be likened to the movement of goods in truck from company A to company B, while transfer refers to the agreements established that permit those goods to be change hands.

sorry, i was confusing things. http really is more than a data transfer protocol, it is an application protocol which works on resources, where GET and PUT are the primary way to send data, and DELETE and friends operates on the resource in a different way, and PROPFIND/PROPPATCH/other DAV style things operate on the resource in yet a different way.

Note that some of these methods involve data, some metadata. POST and friends typically involve an 'action'...

Which is why REST was invented, as as set of terminology for this stuff... I haven't read all the stuff on it, so sometimes use the wrong terms.

"How i explained REST to my wife": http://naeblis.cx/rtomayko/2004/12/12/rest-to-my-wife

Good one, Christoffer.
Thanks to all of you who responded.