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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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 usually do only CRUD operation  which is a simple task  for that its very convenient to use 4 verbs used in HTTP protocol against the 4 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 RESTful application is usually 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 will write a lot shorter methods   One more restraint REST architecture present is not to use session context when communicating with client  stateless   meaning all the information needs 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  therefor 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   that 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 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 opinion that s the main concepts in a teaspoon

User · Answer

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

User · Answer

As I understand it  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 amp 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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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    Web Services can treat each method calls separately  Web Services need not maintain the client s previous interaction  This in turn simplifies application design  HTTP is itself a stateless protocol unlike TCP and thus RESTful Web Services work seamlessly with the HTTP protocols    Disadvantages of Statelessness      One extra layer in the form of heading needs to be added to every request to preserve the client s state  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

[http] What is the difference between HTTP and REST?

Examples related to http

Examples related to rest