HP transportation is a gold sponsor of opentravel.org. Open travel sets standards with the global transportation community and HP is taking a leading role in this area.

1. OPEN-TRAVEL
AND RESTFUL RESOURCES
Championed by the Web community
Roni Schuetz,
Enterprise Software Architect
Miami, April 2012
©2010 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without
notice

2. API Stats
http://www.programmableweb.com/apis

3. API Stats

4. Representational State Transfer
• Fielding captured his interpretation of the
WWW architecture in his 2000 thesis
• Adopted by major vendors (HP, Sabre, Amtrak,
Microsoft, Oracle, Google, Facebook, EBAY, and
others)
• It’s an alternative to WS-* implementations

5. Do we need REST?
• We need a natural way to model resource-based
services: that’s why we are here: OTA!
• We should leverage the principles of the web on
SOA applications
• Some WS-* are too complex and completely
unnecessary(WS-Transfer, WS-Enumeration)
• WS-* interoperability is a big challenge for
internet web services
• Resources provide flexible usage of common
resources and operations which is not given by
WS-*

6. REST in one slide
• Resources expose their data and functionality through resources
identified by a unique URI
• Uniform Interface Principle: Clients interact with resources through a
fix set of verbs
PUT
– Example:
• GET – read
R
• PUT – update GET
• DELETE – remove
• POST – create POST
• Multiple representations for the same resource
– Example: DELETE
• JSON (Java Script Object Notation)
• XML
• Hyperlinks model resource relationships and valid transfer state
transitions for dynamic protocol description and discovery

7. REST Principles
• Resource based - not service based
• Addressability - name everything that matters
• Statelessness - no stateful messages exchange
with a resource
• Relationships - expressed through links
• HTTP based

8. Resource based
• A resource is something “interesting” in your system
– Can be anything
• Spreadsheet
• Printer
• Inventory, Schedule, Flights
– Others?
• Making your system Web-friendly increases its surface
area
• You expose many resources, rather than few web
service endpoints
• Good approach is to think in NOUN’s which appear in
the travel domain
• The VERB’s are the actions on the noun
– sounds familiar

9. HTTP based?
• REST principles are not HTTP dependent
• Typically REST should be implemented as an
HTTP architectural style
• REST expresses dependencies on HTTP specific
concepts such as verbs, URIs and headers
• In the future maybe non HTTP-based REST

10. RESTful Services best practices
• Representation agnostic
• Versioning
• Service Description
• Exception Handling
• Security
• Service Repository

11. Q&A

12. Thank you
Roni Schuetz, roni.schuetz@hp.com

13. References & Resources
• http://www.xml.com/pub/a/2004/12/01/restful-web.html
• http://www.infoq.com/articles/webber-rest-workflow
• http://www.infoq.com/presentations/BPM-with-REST
• http://books.google.ch/books?id=XUaErakHsoAC
• http://www.soapatterns.org/atomic_service_transaction.php
• http://www.soaprinciples.com/service_statelessness.php

14. GET vs. POST Retrieving Paradigm
• To retrieve a “thing” from a Resource we have
2 options:
– The HTTP GET options: PUT
• GET ./order/221
R
GET
• GET ./order?id=221
POST
– The HTTP POST option: DELETE
• POST /order
– id = 221 [key value] … add as much as you need!

15. HTTP Sample for get / post
GET /index.html?userid=joe&password=guessme
HTTP/1.1 Host: www.mysite.com
User-Agent: Mozilla/4.0
POST /login.jsp HTTP/1.1
Host: www.mysite.com
User-Agent: Mozilla/4.0
Content-Length: 27
Content-Type: application/x-www-form-urlencoded
userid=joe&password=guessme
Resource: http://developers.sun.com/mobility/midp/ttips/HTTPPost/

16. The “thing” retrieval pattern PUT
R
GET
• use GET and not POST
POST 1 + POST 2 …. POST n 
• Why not POST?
– Overloaded POST: the not-so-RESTful pattern DELETE
– It’s overloaded because a single HTTP method is
being used to signify any number of non-HTTP
methods.
– By using POST it will happen very easy that we
implement an RPC service. In a RPC service we are
using post and the Action is one of it’s parameters:
”/orders?action=delete&id=13”
• That’s not REST!

17. PUT vs. POST Creation Paradigm
• To create a new “thing” shall I use PUT or
POST?
There is a clear principle for this paradigm:
• If the client is responsible for creating the ID’s of the
“thing” use a PUT
– E.g: “./users/roni” <- roni is unique and given by the client -
this is a new URI!
• If the server is responsible for creating the ID of the
“thing” use a POST
– E.g. “./users/” and as a post key/value the client transfers
username=roni and prob. to id would be an auto generated
number.

18. Resource naming structure pattern
Resource Name: /orders
Action URI Address Template HTTP Method
Create an order /orders POST
Get an order by given ./orders/{id} GET
order id
Update an order ./orders/{id} PUT
Delete an order ./orders/{id} DELETE
Resource semantics:
- plural nouns (resources)
- think of a file system:
- C:ota -> returns a list of files & folders
- C:otadata.txt -> returns the data for this resource
-

19. HTTP status codes on a Resource
Resource Method Status Code CRUD - Action
./Orders POST 200, 201, 400, 503, …. Create
./Orders GET 200, 301, 410, 503, …. Receive
./Orders PUT 200, 301, 400, 410, 503, …. Update
./Orders DELETE 200, 204, 503, …. Delete
Status Code Description
200 OK
201 Created
204 No Content
301 Moved Permanently
400 Bad Request
410 Gone
500 Internal Server Error
501 Not Implemented
503 Service Unavailable
Status Code Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

20. PUT
HTTP HEAD and OPTIONS OPTIONS
There are 2 other HTTP methods which are a part of a URI:
- HEAD: Retrieve a metadata-only representation
GET
POST
R HEAD
- OPTIONS: Check which HTTP methods a particular resource supports
DELETE
HEAD:
- making a call to a resource to fetch metadata without downloading an entire collection
- a client can use HEAD to check if a resource exists, to find out other information about the resource
without fetching it's entire representation. So we have the same functionality like a HTTP GET but now
the call does not fetch data.
OPTIONS:
- The OPTIONS method lets the client to discover what it's allowed to do to a resource. The response to
an OPTIONS request contains the HTTP Allow header, which lays out the subset of the uniform interface
this resource supports.
E.g. : Allow: GET, HEAD
That means that the client can send a GET and HEAD request to this resource but the resource does not
support any other methods - effectively, this resource is read-only.

21. Representations / content negotiation
Web page with a List of process input
form to start a new parameters
process instance
Content Type:
Content Type:
text/html
application/xml
GET /process/name
Content Type:
application/json
Content Type: Content Type:
text/plain image/svg+xml
Process metadata
Basic textutal in JSON
Images / Pictures
description of the
process

22. API Versioning
• This concept makes it very easy to maintain
different versions:
– GET /1.0/orders/ {id}
– GET /1.1/orders/ {id}
– GET /2.1/orders/ {id}
– GET /7.0/orders/
– GET /7.5/orders/
• Make your resource version visible, it’s a big part
for resource usability

23. REST as a new connector
RPC:
Remote Procedure Call
REST / HTTP:
Representational State Transfer
Hypertext Transfer Protocol
R R
ESB:
Enterprise Service Bus R R R
GET / PUT / POST / DELETE
PUBLISH / SUBSCRIBE

24. Working with resources in sync mode
/process
• Client waits until the process
C R is done!
POST /process
DO SOMETHING
ON THE SERVER
200 OK • Block the client until the
Execution
done
execution is done
Note: blocking & non blocking requests are supported by HTTP

25. Working with resources in async mode
/process
• Client starts a long running
C R process
POST /process • Asynchronously process
202 ACCEPTED between the client and the
Location: x
started process
• Retrieve the current state of
the started process
GET /process/x
200 OK
Note: blocking & non blocking requests are supported by HTTP