Representational State Transfer (REST)

6 minute read

Updated:

What is REST?

  • REST is an architectural style for distributed hypermedia systems
  • REpresentational State Transfer
  • What’s interesting is that this style came out in phd thesis – in
    1. And this changed the world – 3%
  • Reason is that this rest as framework states that the existing principles and protocols are enough – you don’t need SOAP, deploying and all. Why can’t we use WS in a more simplistic way?

What does it consist of?

  • Resources – application state and functionality is divided into resources and anything that I access through REST is a resource
  • Universal syntax – every resource is uniquely accessible through universal syntax and for use in hypermedia links
  • Uniform interface – all resources share the same interface, so with one interface you can access all resources behind the actual service and for the transfer of state btwn a client and a resource.
  • You always need an interface, and this will feature constrained set of well-defined operations and a constrained set of content types
  • Protocol that is
    • client/server – send request, then reply back
    • stateless – server is stateless – server forgets who is invoking what – doesn’t keep track of client interaction
    • cacheable – invoke a service and the resource is cached
    • layered – in terms of functionalities on client and server side.
  • end of the day, we have access to number of resources that is clearly constrained

Why is it called “Representation State Transfer”?

  • However, more interesting – what is state and transfer?
  • E.g. where you have a client and you access a resource through URI, where it’s to do with the aircraft. Then client needs to get info coz they gotta do maintenance work of the aircraft.
    • Web resource is a URL – server returns a representation of the resource. Here’s a rep of what your asking for – i.e. html doc
    • The representation will put the client into diff state as they are having access to 787.html
    • It will traverse the link and will find other resource – then ur exposed to new representation hence a change of state
  • State keeps changing, and it transfers from one to another

The REST way of implementing the Web Services

  • image
    1. Get part list – use URL 1, look at the server, change the state, and client gets HTTP response through that invocation
    2. Get detailed information about a particular part – client gets a document of list as an html, and looks through the doc. Therefore, it invokes another service part 2, through second URL and get http response
    3. Submit a purchase order (PO) – if the client is happy with the part info, then they will send the HTTP POST to response purchase order
    • Keep this slide in mind, we’ll get back.
  1. Get a list of parts → First invocation
    • The restful service will send back a part list. URI through

    http://www.parts-depot.com/parts

    • If we want to specify the type of document, we need to specify our flavour – to xml or json
    • Data Returned – Parts List III
    • Parts list has links to get detailed information about each part. → key feature of REST
    • By client invoking one of the lists, client transfers from one state to the next by examining and choosing from among the alternative URLs
  2. Get information about a particular part
    • RESTful WS makes available a URI to each part resource
    • BUT it’s not a true physical URI !!its coz if we had one million, we don’t wanna associate each one with one million. - What we are expressing here is what resource is desired - it is a logical URI - Data Returned
    • In the HTML doc that got sent back to a client, there’s another link, saying that here’s a specification if you need it → Again we don’t need one million, it’s logical URI
    • Data is linked to still more data – specification for this part is found by traversing the hyperlink → you access the resource and change the state.
  3. Service: Submit a Purchase Order (PO)
    • As opposed to first and second, this will be done in HTTP post – you make sure that you conform to a XML schema definition. RESTful server will ensure that my purchase conforms to this
    • Once client submits PO through HTTP post – server will take that into consideration

## Claimed Benefits

  • Provides improved response times – caching comes as a plus
  • Improves server scalability – bc servers are stateless, it doesn’t need to handle subsequent request or no need to remember what happened before
  • Depends less on vendor software – don’t need any software in terms of web and messaging framework – http should be enough → main benefit!
  • Provides equivalent functionality - compared to SOAP, can have same functionality
  • Does not require a separate resource discovery mechanism – since everything is http and hyperlink. As long as you know what the API is needed to access the resource, should be enough
  • Provides better long-term compatibility and evolvability – better than RPC (used for SOAP) – if you have more parts, and you change info regarding one part, the compatibility is maintained. Bc content types are defined without dropping or reducing the support of other content types.

Implementing the Web Services using SOAP

  • Difference btwn service using SOAP and REST- compare [9 pdf 10] and [9 pdf 19]
  • URLs
    • SOAP – we use one URL to access the service. URL1 to get list, get part and to submit. So soap we need to specify what the name of the method we are invoking – getPartList()
    • REST it uses all diff URLs for each – URL1,2, and 3.
  • HTTP invocation
    • REST - to get the part list, we used HTTP GET and to order, we used HTTP POST
    • SOAP – its all through HTTP POST.
  • Major diff is to do with karim is overhead
    • Q: Can we quantify how many operations we need to make this happen?
      • SOAP - To have part list, client needs to make a request (SOAP msg), then it goes into an envelope → so the soap message here is petty huge in terms of size. Send it through URL, and when soap server gets it, it needs to realize the envelop, open it and interpret the msg and invoke the method
      • The overhead here is huge!!

REST vs SOAP differences

Criteria SOAP REST
Find target resource Look inside envelope URI and HTTP method – it’s enough to access the method
Caching No Yes- better performance
Semantic Web Vision – how you allow computers to actually understand the data available online? Tools must be customised on a per-application basis bc you need interpretation as a plus

  • Consistent with the vision

  • Every resource has a logical URI

  • Generic interface
Interoperability Many many standards and btwn vendors it may not work Only HTTP – so easier
Interface definition Operates through diff interfaces Single uniform interface – have one and access many resources
Standards available Defines standards to be strictly followed Doesn’t define much
Simplicity More complex due to more standards Simpler thanks to HTTP protocols
Scalability More scalable bc server is stateless

How to bring some semantic on any resource that we access on web

  • Is through a framework RDF – Resource Description Framework
  • There’s a language associated with semantic web called OWL
  • Ontologies – if we create ontology, we have reason about the data once it is represented through this framwwork

Conclusions

  • There is a big debate in the WS community about whether to use REST/SOAP
  • Lot of Web services is 80% REST, and 20% SOAP → still need legacy support of soap
  • Many companies are offering their Web services using REST, example:
    • Twitter, Search API, Maps, live, photos, traffic etc
SOAP REST
appropriate for larger, formal applications that require advanced capabilities between relatively homogenous systems. has grown in popularity primarily due to its ease of implementation
has rich functionality but at the expense of interoperability. considered to be faster than SOAP (Amazon claim that REST is up to six times faster)
  very attractive for basic applications that involve high levels of interoperability between multiple platforms

Leave a comment