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.

Iterative

Just as a side note, probably 90% of the hype that you hear about REST these days are from people who don't actually understand the complete picture about REST. REST unfortunately has become a sales buzzword. You have to cut through a lot of crap to find out the real benefits. – Needlewoman

The hype around REST is probably due to people being heavily annoyed by SOAP. Everybody's just happy to escape the SOAP hell :D – Typeface

I'm the newbie coder at work here, and SOAP issues and moving away from it is how I ended up here. Thanks for the verification it is indeed HTTP. I was also confused. – Antidote

Think of HTTP as a ball to play games with and REST as a specific game such as Soccer. Some will say soccer is the best game, others will disagree. Why does it deserve it's own term? Because calling all ball games, "ball game" means there's no way of determining which rule-set you are using. This way, everyone is reading from the same song sheet (sorry, mixed metaphor) – Hawker

Now we have another option GraphQL compared with REST. Both are using HTTP. – Naashom

Exactly these questions came to my mind when learned about REST. And felt there is nothing new Roy Fielding invented in here. He just treated HTTP methods for direct database like operations (GET for read, PUT for write, POST for add etc) That was all about it. Please correct me if I am wrong. "I'm not sure whether this deserves a term of its own, and I certainly don't get the hype around it." seriously cannot agree more. – Idonah

@RossDrew great analogy.. it makes more easier to understand. – Elmiraelmo

Answer 1

No, REST is the way HTTP should be used.

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.

For example, REST dictates the usage of DELETE to erase a document (be it a file, state, etc.) behind a URI, whereas, with HTTP, you would misuse a GET or POST query like ...product/?delete_id=22.

Typeface

And what would be the big advantage of using those other methods? – Iterative

I posted a link to a real world example that would show you the advantages. Cheers. – Typeface

-1 for giving wrong definition to rest. rest is a type of architecture, not a way to send messages via web. for more information: en.wikipedia.org/wiki/Representational_state_transfer – Pyromagnetic

@user2033402 I cite: "Can someone explain what functionality REST adds to HTTP?". So, you'd answer that question with: "[...] is a type of architecture"? *shaking my head* – Typeface

Rest, by itself, doesn't add any functionality to http. Rest is commonly used in a certain way using the http protocol, but this is not part of rest. you can use only post verbs and as long as you keep the restful server design, and all the information needed for communication is transferred in hypermedia representation, that would still be a restful application. Even if that is the answer he was looking for, that answer is wrong. It gives wrong information and defines concepts wrong. If this is what you would say in a job interview you would fail. Its a wrong description of rest – Pyromagnetic

@user2033402 Look, I'll break it down to you the simple way: REST is the architectural principle behind the HTTP/1.0 protocol. HTTP itself adheres to the REST architectural style, thus enabling you and me to write RESTful applications. Exchanging messages is a big part of such applications and one that is left to the developer to implement. Thankfully, HTTP offers a handful of standard methods (GET, POST etc.), "verbs" as you call them, that lend semantics (part of self-descriptivness) to different types of messages within your application for free, so you don't have to reinvent the wheel. – Typeface

wrong again. REST is NOT the architectural principle behind http/1.0 protocol. RESTful architecture was invented a lot later. The functionalities offered by the http protocol fits REST architecture, but the 2 are not dependent on one another. its not a question of reinventing the wheel, its a question of understanding these concepts – Pyromagnetic

Let me quote the dissertation: "The first edition of REST was developed between October 1994 and August 1995, primarily as a means for communicating Web concepts as we wrote the HTTP/1.0 specification and the initial HTTP/1.1 proposal. It was iteratively improved over the next five years and applied to various revisions and extensions of the Web protocol standards.". You strike me as a "Korinthenkacker", not worth debating any further. Thank you. Good by. – Typeface

@Typeface thank you, i didnt know that, and never read the full dissertation. i would change the votedown to voteup if it wasnt locked. you have an interesting way of debating, you could just give me a link and be done with that. shish. – Pyromagnetic

@Typeface You said No, REST is the way HTTP should be used. 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. Agreed But its the developer fault who are not using all HTTP protocol. Even REST just recommends ( does not enforce ) to use Delete method instead of POST to delete any resource. So developers can also misuse the REST in the same way as HTTP verbs. Is n't it ? – Zeba

@emily I wouldn't call it misuse. You could go ahead and adhere to REST principles without any notion of "verbs" on the transport protocol at all. You would just have to reinvent the wheel and establish your own RESTy protocol on top of that (e.g. within the payload, as part of the URL or even inside cookies – doesn't matter). Either way, it's all about convention, helping a client (be it user or machine) to search, view and manipulate resources on the web. HTTP in this regard offers you a set of methods which, if applied correctly, provide a well thought out scaffold for RESTful applications. – Typeface

-1 for REST is NOT the way HTTP should be used.Which method should I use when I want to add a login api? GET?POST? Should I use json in POST body or should I use http query in POST body? REST just make things complex and not consistent. I can just use POST and json to do whatever I want.I do not want to care about GET/POST/DELETE stuff. – Roussel

So, can we say that all REST APIs are HTTP APIs, but the reciprocal is false? – Somnambulism

Re: "-1 for giving wrong definition to rest. rest is a type of architecture, not a way to send messages via web. for more information: en.wikipedia.org/wiki/Representational_state_transfer" by @Yuval Perelman: ok, but... the latter is a consequence of the former. The way to send messages in REST must obey the REST architecture. It's as if you'd say: "sustainability is a way to architect houses, not a way to build a house...". The builders will obviously build inline with the architecture defined for that sustainable house... – Somnambulism

Answer 2

HTTP is a protocol used for communication, usually used to communicate with internet resources or any application with a web browser client.

REST means that the main concept you are using while designing the application is the Resource: for each action you want to perform you need to define a resource on which you often do only CRUD operation, which is a simple task. For that it's very convenient to use four verbs used in HTTP protocol against the four CRUD operations (GET for Read, POST is for CREATE, PUT is for UPDATE and DELETE is for DELETE).

That's unlike the older concept of RPC (Remote Procedure Call), in which you have a set of actions you want to perform as a result of the user's call. if you think for example on how to describe a Facebook like on a post, with RPC you might create services called AddLikeToPost and RemoveLikeFromPost, and manage it along with all your other services related to FB posts, thus you won't need to create special object for Like.

With REST you will have a Like object which will be managed separately with Delete and Create functions. It also means it will describe a separate entity in your DB. That might look like a small difference, but working like that would usually yield a much simpler code and a much simpler application. With that design, most of the app's logic is obvious from the object's structure (model), unlike RPC with which you would usually have to explicitly add a lot more logic.

Designing a RESTful application is often a lot harder because it requires you to describe complicated things in a simple manner. Describing all functionalities using only CRUD functions is tricky, but after doing that your life would be a lot simpler, and you will find that you write a lot shorter methods.

One more restraint REST architecture presents is not to use a session context when communicating with a client (stateless), meaning all the information needed to understand who is the client and what he wants is passed with the web message. Each call to a function is self-descriptive, there is no previous conversation with the client which can be referenced in the message. Therefore, a client could not tell you "give me the next page" since you don't have a session to store what is the previous page and what kind of page you want, the client would have to say "my name is Yuval, get me page 2 of a specific post in a specific forum". This means a bit more data would have to transfer in the communication, but think of the difference between finding a bug reported from the "get me the next page" function in oppose to "get me page 2 of question ID 2190836 in stack overflow".

Of course there is a lot more to it, but to my humble opinion these are the main concepts in a teaspoon.

Pyromagnetic

Answer 3

REST enforces the use of the available HTTP commands as they were meant to be used.

For example, I could do:

GET
http://example.com?method=delete&item=xxx

But with rest I would use the "DELETE" request method, removing the need for the "method" query param

DELETE
http://example.com?item=xxx

Azar

Simple example that saves a 1000 word. – Kibler

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.

Needlewoman

Answer 5

HTTP is a contract, a communication protocol and REST is a concept, an architectural style which may use HTTP, FTP or other communication protocols but is widely used with HTTP.

REST implies a series of constraints about how Server and Client should interact. HTTP is a communication protocol with a given mechanism for server-client data transfer, it's most commonly used in REST API just because REST was inspired by WWW (world wide web) which largely used HTTP before REST was defined, so it's easier to implement REST API style with HTTP.

There are three major constraints in REST (but there are more):

1. Interaction between server and client should be described via hypertext only.
2. Server and client should be loosely coupled and make no assumptions about each other. Client should only know resource entry point. Interaction data should be provided by the server in the response.
3. Server shouldn't store any information about request context. Requests must be independent and idempotent (means if same request is repeated infinitely, exactly same result is retrieved)

And HTTP is just a communication protocol (a tool) that can help to achieve this.

For more info check these links:

• https://martinfowler.com/articles/richardsonMaturityModel.html
• http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Notarial

Answer 6

REST = Representational State Transfer

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

REST is a protocol to exchange any(XML, JSON etc ) messages that can use HTTP to transport those messages.

Features:

It is stateless which means that ideally no connection should be maintained between the client and server. It is the responsibility of the client to pass its context to the server and then the server can store this context to process the client's further request. For example, session maintained by server is identified by session identifier passed by the client.

Advantages of Statelessness:

1. Web Services can treat each method calls separately.
2. Web Services need not maintain the client's previous interaction.
3. This in turn simplifies application design.
4. HTTP is itself a stateless protocol unlike TCP and thus RESTful Web Services work seamlessly with the HTTP protocols.

Disadvantages of Statelessness:

1. One extra layer in the form of heading needs to be added to every request to preserve the client's state.
2. For security we need to add a header info to every request.

HTTP Methods supported by REST:

GET: /string/someotherstring It is idempotent and should ideally return the same results every time a call is made

PUT: Same like GET. Idempotent and is used to update resources.

POST: should contain a url and body Used for creating resources. Multiple calls should ideally return different results and should create multiple products.

DELETE: Used to delete resources on the server.

HEAD:

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The meta information contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request.

OPTIONS:

This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

HTTP Responses

Go here for all the responses.

Here are a few important ones: 200 - OK 3XX - Additional information needed from the client and url redirection 400 - Bad request
401 - Unauthorized to access
403 - Forbidden
The request was valid, but the server is refusing action. The user might not have the necessary permissions for a resource, or may need an account of some sort.

404 - Not Found
The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.

405 - Method Not Allowed A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via POST, or a PUT request on a read-only resource.

404 - Request not found
500 - Internal Server Failure
502 - Bad Gateway Error

Portsalut

IMO this deserves more up-votes. – Thayer

Answer 7

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.

Buckjump

The guy who asked the question...."After reading a lot about the differences between REST and SOAP" – Buckjump

Answer 8

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.

Clitoris

I'd say that if you use HTTP as a transport for your REST service it's easy to obey those rules. – Wrac

Answer 9

From You don't know the difference between HTTP and REST

So REST architecture and HTTP 1.1 protocol are independent from each other, but the HTTP 1.1 protocol was built to be the ideal protocol to follow the principles and constraints of REST. One way to look at the relationship between HTTP and REST is, that REST is the design, and HTTP 1.1 is an implementation of that design.

Ha

Answer 10

HTTP is a communications protocol that transports messages over a network. SOAP is a protocol to exchange XML-based messages that can use HTTP to transport those messages. Rest is a protocol to exchange any(XML or JSON) messages that can use HTTP to transport those messages.

Prude

Your answer does not answer the question. – Potpourri

Your HTTP and SOAP definition was great and cleared up the question for me. But I do not believe Rest is a protocol. It is an architectural guideline which enforces the correct use of the HTTP transport protocol. – Risley

Answer 11

REST is not necessarily tied to HTTP. RESTful web services are just web services that follow a RESTful architecture.

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

Tenaculum

HTTP is 1-Client-server, 2-stateless, 3-casheable. Then What extra features/constraints REST put on HTTP? What can we do with REST that cannot be done with HTTP alone? – Staley

Answer 12

REST APIs must be hypertext-driven

From Roy Fielding's blog here's a set of ways to check if you're building a HTTP API or a REST API:

API designers, please note the following rules before calling your creation a REST API:

• A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. [Failure here implies that identification is not separated from interaction.]
• A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP’s PATCH method or Link header field. Workarounds for broken implementations (such as those browsers stupid enough to believe that HTML defines HTTP’s method set) should be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces are object-specific, not generic.]
• A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]
• A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC’s functional coupling].
• A REST API should never have “typed” resources that are significant to the client. Specification authors may use resource types for describing server implementation behind the interface, but those types must be irrelevant and invisible to the client. The only types that are significant to a client are the current representation’s media type and standardized relation names. [ditto]
• A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

Arevalo

Answer 13

REST is a light version of SOAP, with no sugars or colors agents added.
The goal of both SOAP and REST is to allow the communication between Information Systems that may be written in different languages and use different communiation protocols.

While SOAP uses API contracts to expose it's services and define the way a client can call a service, what Parameters should be sent and what results are to be expected, REST on the other hand has uses no API contracts, for a client to know what services exist and how to call them it should look into the Rest API documentation (this can be defined in a yml file with a OpenAPI or Swagger).

Second SOAP is verbose, it reyes on XML to send a request and describe the services, parameteres and the results returned. On the other hand REST relyed on simple JSON Objects to send requests and receive results. JSON is simple to undersand, lightweight and does not use too much bandwith when sending requests or receiving results.

Ednaedny