REST is an oft misunderstood term. The precise definition can of course be found in Fielding's dissertation, and is attempted explained in the Wikipedia entry. In short it's an architectural style, and has nothing technically to do with HTTP or the web. HTTP and a lot of the web, however enable and follow the REST architectural style.
But in truth the term REST has been watered down and it now is almost synonymous with HTTP based API of some sort.
When developers talk about implementing or using a REST API they usually mean something along the lines of documenting URI templates for all their resources, and use GET to retrieve something, PUT to modify something, DELETE to delete something and POST to do anything else (like create or accept or modify something), like the Twitter API to update ones status or StackOverflow's own API or Facebook's API.
These APIs typically
- give each interesting thing (resource) in their system their own URI
- use the "uniform interface" (GET, PUT, POST, DELETE) on these URIs to work with
the resources
- use standard types of authentication schemes (like OAuth or OpenID or even
simpler variants)
- are stateless, in that each request is independent of any previous request
All these are good, and required of REST architectures, but alone aren't enough to follow the academic REST
I think this is a fitting description for REST as it is now. There are a few people who understand the difference between Corporate REST and Academic REST but their numbers are dwindling.
But that's the topic of another question, just search for HATEOAS.
