Categories
architecture definition http rest

What is RESTful programming?

4129

What exactly is RESTful programming?

7

805

An architectural style called REST (Representational State Transfer) advocates that web applications should use HTTP as it was originally envisioned. Lookups should use GET requests. PUT, POST, and DELETE requests should be used for mutation, creation, and deletion respectively.

REST proponents tend to favor URLs, such as

http://myserver.com/catalog/item/1729

but the REST architecture does not require these “pretty URLs”. A GET request with a parameter

http://myserver.com/catalog?item=1729

is every bit as RESTful.

Keep in mind that GET requests should never be used for updating information. For example, a GET request for adding an item to a cart

http://myserver.com/addToCart?cart=314159&item=1729

would not be appropriate. GET requests should be idempotent. That is, issuing a request twice should be no different from issuing it once. That’s what makes the requests cacheable. An “add to cart” request is not idempotent—issuing it twice adds two copies of the item to the cart. A POST request is clearly appropriate in this context. Thus, even a RESTful web application needs its share of POST requests.

This is taken from the excellent book Core JavaServer faces book by David M. Geary.

9

  • 2

    Lisiting Available Idempotent Operations: GET(Safe), PUT & DELETE (Exception is mentioned in this link restapitutorial.com/lessons/idempotency.html). Additional Reference for Safe & Idempotent Methods w3.org/Protocols/rfc2616/rfc2616-sec9.html

    – Abhijeet

    Jul 21, 2015 at 4:00

  • 5

    a) the important point about GET is safeness, not idempotence, b) @Abhijeet: RFC 2616 has been obsoleted in 2014; see RF 7230ff.

    May 6, 2016 at 6:16


  • 20

    This is wrong. Read this for correct interpretation of REST roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven or this stackoverflow.com/questions/19843480/…

    Aug 25, 2017 at 7:09


  • 6

    @kushalvm That academic definition of REST is not used in practice.

    Aug 27, 2017 at 15:31

  • 4

    Effectively we can wonder if a concept is operational since we fail to simple give it a stable and understandable definition for all

    – HoCo_

    May 3, 2018 at 23:03


805

An architectural style called REST (Representational State Transfer) advocates that web applications should use HTTP as it was originally envisioned. Lookups should use GET requests. PUT, POST, and DELETE requests should be used for mutation, creation, and deletion respectively.

REST proponents tend to favor URLs, such as

http://myserver.com/catalog/item/1729

but the REST architecture does not require these “pretty URLs”. A GET request with a parameter

http://myserver.com/catalog?item=1729

is every bit as RESTful.

Keep in mind that GET requests should never be used for updating information. For example, a GET request for adding an item to a cart

http://myserver.com/addToCart?cart=314159&item=1729

would not be appropriate. GET requests should be idempotent. That is, issuing a request twice should be no different from issuing it once. That’s what makes the requests cacheable. An “add to cart” request is not idempotent—issuing it twice adds two copies of the item to the cart. A POST request is clearly appropriate in this context. Thus, even a RESTful web application needs its share of POST requests.

This is taken from the excellent book Core JavaServer faces book by David M. Geary.

9

  • 2

    Lisiting Available Idempotent Operations: GET(Safe), PUT & DELETE (Exception is mentioned in this link restapitutorial.com/lessons/idempotency.html). Additional Reference for Safe & Idempotent Methods w3.org/Protocols/rfc2616/rfc2616-sec9.html

    – Abhijeet

    Jul 21, 2015 at 4:00

  • 5

    a) the important point about GET is safeness, not idempotence, b) @Abhijeet: RFC 2616 has been obsoleted in 2014; see RF 7230ff.

    May 6, 2016 at 6:16


  • 20

    This is wrong. Read this for correct interpretation of REST roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven or this stackoverflow.com/questions/19843480/…

    Aug 25, 2017 at 7:09


  • 6

    @kushalvm That academic definition of REST is not used in practice.

    Aug 27, 2017 at 15:31

  • 4

    Effectively we can wonder if a concept is operational since we fail to simple give it a stable and understandable definition for all

    – HoCo_

    May 3, 2018 at 23:03


548

RESTful programming is about:

  • resources being identified by a persistent identifier: URIs are the ubiquitous choice of identifier these days
  • resources being manipulated using a common set of verbs: HTTP methods are the commonly seen case – the venerable Create, Retrieve, Update, Delete becomes POST, GET, PUT, and DELETE. But REST is not limited to HTTP, it is just the most commonly used transport right now.
  • the actual representation retrieved for a resource is dependent on the request and not the identifier: use Accept headers to control whether you want XML, HTTP, or even a Java Object representing the resource
  • maintaining the state in the object and representing the state in the representation
  • representing the relationships between resources in the representation of the resource: the links between objects are embedded directly in the representation
  • resource representations describe how the representation can be used and under what circumstances it should be discarded/refetched in a consistent manner: usage of HTTP Cache-Control headers

The last one is probably the most important in terms of consequences and overall effectiveness of REST. Overall, most of the RESTful discussions seem to center on HTTP and its usage from a browser and what not. I understand that R. Fielding coined the term when he described the architecture and decisions that lead to HTTP. His thesis is more about the architecture and cache-ability of resources than it is about HTTP.

If you are really interested in what a RESTful architecture is and why it works, read his thesis a few times and read the whole thing not just Chapter 5! Next look into why DNS works. Read about the hierarchical organization of DNS and how referrals work. Then read and consider how DNS caching works. Finally, read the HTTP specifications (RFC2616 and RFC3040 in particular) and consider how and why the caching works the way that it does. Eventually, it will just click. The final revelation for me was when I saw the similarity between DNS and HTTP. After this, understanding why SOA and Message Passing Interfaces are scalable starts to click.

I think that the most important trick to understanding the architectural importance and performance implications of a RESTful and Shared Nothing architectures is to avoid getting hung up on the technology and implementation details. Concentrate on who owns resources, who is responsible for creating/maintaining them, etc. Then think about the representations, protocols, and technologies.

12

  • 37

    An answer providing a reading list is very appropriate for this question.

    – ellisbben

    Feb 1, 2012 at 19:50

  • 26

    Thanks for the update. PUT and POST don’t really map one-to-one with update and create. PUT can be used to create if the client is dictating what the URI will be. POST creates if the server is assigning the new URI.

    – D.Shawley

    Feb 1, 2012 at 23:30

  • 4

    A URN is a URI that uses the urn: scheme. Conceptually there is no difference; however, a URN does require that you have a separately defined method to “locate” the resource identified (named) by the URN. Care must be taken to ensure that you don’t introduce implicit coupling when relating named resources and their location.

    – D.Shawley

    Mar 30, 2014 at 14:45

  • 2

    @ellisbben Agreed. If I understand correctly this is the dissertation that gave rise to REST: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

    Sep 10, 2014 at 12:56

  • 2

    One doubt on this point: “the actual representation retrieved for a resource is dependent on the request and not the identifier: use HTTP Accept headers to control whether you want XML, HTTP, or even a Java Object representing the resource” –Here, should it be “…whether you want XML, HTML, or even a Java Object representing the resource…” I am thinking that HTTP Accept headers tells the format for data exchanged. And HTTP is the protocol used in RESTel web APIs

    Nov 27, 2014 at 9:34