What is the difference between HTTP and REST?

Question

After reading a lot about the differences between REST and SOAP, I got the impression that REST is just another word for HTTP. Can someone explain what functionality REST adds to HTTP?

Note: I'm not looking for a comparison of REST versus SOAP.

Update: Thanks for your answers. Now it has become clear to me that REST is just a set of rules about how to use HTTP. Hence I posted a follow-up about what the advantages of these conventions are .

Note: I now grasp the meaning of REST; as Emil Ivanov remarks, REST means using HTTP the way it's meant to be. However, I'm not sure whether this deserves a term of its own, and I certainly don't get the hype around it.

Answer 1

Not quite...

http://en.wikipedia.org/wiki/Representational_State_Transfer

REST was initially described in the context of HTTP, but is not limited to that protocol. RESTful architectures can be based on other Application Layer protocols if they already provide a rich and uniform vocabulary for applications based on the transfer of meaningful representational state. RESTful applications maximise the use of the pre-existing, well-defined interface and other built-in capabilities provided by the chosen network protocol, and minimise the addition of new application-specific features on top of it.

http://www.looselycoupled.com/glossary/SOAP

(Simple Object Access Protocol) The standard for web services messages. Based on XML, SOAP defines an envelope format and various rules for describing its contents. Seen (with WSDL and UDDI) as one of the three foundation standards of web services, it is the preferred protocol for exchanging web services, but by no means the only one; proponents of REST say that it adds unnecessary complexity.

Answer 2

No, REST is the WAY we all should use HTTP. Today we only use a tiny bit of the HTTP protocol's methods - namely GET and POST. The REST way to do it is to use all of the protocol's methods.

REST for example dictates the usage of DELETE to erase a document (be it a file, a state or whatever) behind a URI, whereas you would missuse a GET or POST query like ...product/?delete_id=22 without REST.

There's a well done example on http://bitworking.org/news/201/RESTify-DayTrader.

Answer 3

REST doesn't add any specific functionality to HTTP but is an architectural style that was developed alongside HTTP and most commonly uses HTTP for its application layer protocol.

Answer 4

HTTP is an application protocol. REST is a set of rules, that when followed, enable you to build a distributed application that has a specific set of desirable constraints.

If you are looking for the most significant constraints of REST that distinguish a RESTful application from just any HTTP application, I would say the "self-description" constraint and the hypermedia constraint (aka Hypermedia as the Engine of Application State (HATEOAS)) are the most important.

The self-description constraint requires a RESTful request to be completely self descriptive in the users intent. This allows intermediaries (proxies and caches) to act on the message safely.

The HATEOAS constraint is about turning your application into a web of links where the client's current state is based on its place in that web. It is a tricky concept and requires more time to explain than I have right now.

Answer 5

REST is a specific way of approaching the design of big systems (like the web).

It's a set of 'rules' (or 'constraints').

HTTP is a protocol that tries to obey those rules.