Representational State Transfer REST

1
Representational State Transfer (REST)

• Andrei Ionita
• a.ionita_at_jacobs-university.de
• KWARC Research Group
• and
• DFKI Lab Bremen
• June, 2007

2
What is REST?

• Network Architectural style
• Coined by Roy Fielding in his Ph.D. dissertation
  in 2000
• Overview
• Resources are defined and addressed
• Transmits domain-specific data over HTTP
• Does not have any SOAP messaging layer or HTTP
  cookies

3
Resources

• Web is comprised of resources, e.g. BMW defines
  Z4 Coupé as a resource
• Users access it with the URL http//www.bmw.com/e
  n/newvehicles/Z4/Coupe
• A representation is returned, e.g.Z4Coupe.html
• This representation puts the client application
  in a state
• Accessing another hyperlink, e.g. accessories
  transfers the client application into another
  state

4
REST is not a standard

• No W3C specification (EDIT But there is an XML
  database that has such an API eXist)
• REST is built on the concepts
• HTTP (transferring mechanism)
• URL (resource address)
• XML/HTML/GIF/JPEG (Resource representations)
• text/xml, text/html, image/gif, image/jpeg (MIME
  types)

5
Web services Company example

• Build a web service to enable its customers to
• Get list of items
• Get details about a particular item
• Purchase Order (PO)

6
A user session
List of Items
Item Data
Time
Web Server
PO (HTML/XML)
PO
HTTP POST
PO.xml
7
Get list of items

• Access the URL http//www.company.com/items
• How the list is generated is invisible to the
  user (loose coupling)
• The following XML document returned
• Each item is retrieved via other links (key
  feature)

8
Get detail of an item

• Accessing the URL http//www.company.com/items/00
  345
• Any data change will not affect the user as in
  accessing http//www.company.com/items/00345.html
  (restricts the resource whereas a database could
  be underneath)
• Again, more in-depth links appear, enabling to
  more detailed information

9
Submit Purchase Order (PO)

• On the client, an instance is created, e.g. form
• client submits PO.xml as the payload of an HTTP
  POST
• The server responds to the POST with an URL
• The order is shared information between the
  company and the client (the client may DELETE it)

10
Characteristics

• Traversing links pulls representations
  (pull-based client-server interaction)
• Each request must be self-sufficient, not taking
  advantage of any store resource (stateless)
• Capability of storing responses to frequent
  requests (cacheable or non-cacheable)
• Resources are access via (HTTP) GET, POST, PUT,
  DELETE (uniform interface)
• Every resource is named using an URL (named
  resources)
• Resources are interconnected using URLs
  (interconnected resource representations)
• Intermediate components, e.g. proxy servers,
  gateways, firewalls, etc. can be inserted between
  clients and resources for performance, security
  (layered components)

11
Steps in creating a RESTful system

• 1. Identify resources, e.g. list of items, detail
  of an item, purchase order
• 2. Create a URL for every resource
• use nouns, not verbs
• http//www.company.com/items/00345
• Instead of
• http//www.company.com/items/getItem?id00345
• Categorize resources
• Accessible via HTTP GET (read-only)
• Accessible also via POST, PUT, DELETE
  (modifiable)
• Connect resources through hyperlinks
• Specify the format of the response using a
  schema, e.g. DTD, W3C schema, RelaxNG (also take
  care of POST or PUT services)
• Describe how your services should be invoked (in
  a WSDL or HTML document)

12
REST Constrains (1)

• Client/Server constraints
• Separation of Concerns
• Independent evolution of Components
• Stateless Constraint
• Single request reveals everything
• Easier to recover from failures
• Server does not commit resources to each request
• May degrade network performance when having large
  requests
• Caching constraint
• Eliminates interactions
• Clients have the right to reuse cacheable data
• May degrade reliability due to stale data

13
REST Constrains (2)

• Uniform interface constrain
• Implementation decoupled from interfaces
• Adapting degrades efficiency
• Layered system constraint
• Architecture can be build hierarchically
• Added Overhead
• Code-on-demand (inactive code is executed on the
  client when the user requests it)

14
Advantage to SOAP technology
15
References

• Main reference
• Roger L. Costello, Building the Web Services the
  REST way, http//www.xfront.com/REST-Web-Services.
  html
• Additional references
• Paul Prescod, Second Generation Web Services,
  http//webservices.xml.com/pub/a/ws/2002/02/06/res
  t.html?page1
• Wikipedia article, http//en.wikipedia.org/wiki/R
  epresentational_State_Transfer
• Henning Niss, REST for Web Services
• http//www.itu.dk/courses/IWSJ/E2005/slides/lectu
  re7.pdf
• Hao He, Implementing REST Web Services Best
  Practices and Guidelines
• http//www.xml.com/pub/a/2004/08/11/rest.html?pag
  e1
• Ryan Tamayko, How I explained REST to my wife
  http//tomayko.com/articles/2004/12/12/rest-to-my-
  wife