The rising complexity and cost of managing legacy travel distribution systems are leading many travel companies today to adopt a REST (REpresentational State Transfer) architectural style because it provides standardized resources that enable precise interaction with other REST systems. The panelists will discuss the fundamental shift in application design required to begin thinking in terms of resources rather than objects and methods and how the OpenTravel 2.0 specification is being designed to provide a common XML resource model for the travel industry.

1. 2012 North American Advisory Forum (Miami  Florida  April 2012)
PANEL PRESENTATION
OpenTravel and RESTful Resources
The rising complexity and cost of managing legacy travel
distribution systems are leading many travel companies
today to adopt a REST (REpresentational State Transfer)
architectural style because it provides standardized
resources that enable precise interaction with other REST
systems. The panelists will discuss the fundamental shift in
application design required to begin thinking in terms of
resources rather than objects and methods and how the
OpenTravel 2.0 specification is being designed to provide a
common XML resource model for the travel industry.

2. 2012 North American Advisory Forum (Miami  Florida  April 2012)
Panel Participants
RONI SCHUETZ, Enterprise Software
DAVID MORLEY, Technical Consultant,
Architect, Hewlett Packard (panelist,
Marriott International (moderator)
presenter)
DAVE HOLLANDER, Enterprise Architect, Sabre Technology (panelist)
BRYON JACOB, Chief Architect, HomeAway
STUART WALDRON, Information Technology Architect, Amtrak

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

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

5. 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, …
others ??)
• It’s an alternative to WS-* implementations

6. Do we need REST?
• We need a natural way to model resource-based
services: that’s why we are here: OpenTravel!
• 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-*

7. 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

8. 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

9. 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

10. 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

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

12. 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

13. 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!

14. 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/

15. 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!

16. 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.

17. 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
-

18. 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

19. 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.

20. 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

21. 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

22. 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

23. 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

24. 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