PANEL PRESENTATION

2012 North American Advisory Forum (Miami Florida April 2012)

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.

2012 North American Advisory Forum (Miami Florida April 2012)

Panel Participants

RONI SCHUETZ, Enterprise Software

Architect, Hewlett Packard (panelist,

presenter)

DAVID MORLEY, Technical Consultant,

Marriott International (moderator)

DAVE HOLLANDER, Enterprise Architect, Sabre Technology (panelist)

BRYON JACOB, Chief Architect, HomeAway

STUART WALDRON, Information Technology Architect, Amtrak

©2010 Hewlett-Packard Development Company, L.P.

The information contained herein is subject to change without

notice

OPENTRAVEL

AND RESTFUL RESOURCES

Roni Schuetz,

Enterprise Software Architect

OpenTravel Advisory Forum

Miami, April 2012

Championed by the Web community

API Stats

http://www.programmableweb.com/apis

• 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

Representational State Transfer

• 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-*

Do we need REST?

• 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 – Example:

• GET – read • PUT – update • DELETE – remove • POST – create

• Multiple representations for the same resource – Example:

• JSON (Java Script Object Notation) • XML

• Hyperlinks model resource relationships and valid transfer state transitions for dynamic protocol description and discovery

REST in one slide

R PUT

GET

POST

DELETE

• Resource based - not service based

• Addressability - name everything that matters

• Statelessness - no stateful messages exchange with a resource

• Relationships - expressed through links

• HTTP based

REST Principles

• 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

Resource 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

HTTP based?

• Representation agnostic

• Versioning

• Service Description

• Exception Handling

• Security

• Service Repository

RESTful Services best practices

• 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

References & Resources

• To retrieve a “thing” from a Resource we have 2 options:

– The HTTP GET options:

• GET ./order/221

• GET ./order?id=221

– The HTTP POST option:

• POST /order – id = 221 [key value] … add as much as you need!

GET vs. POST Retrieving Paradigm

R PUT

GET

POST

DELETE

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/

• use GET and not POST

• Why not POST? – Overloaded POST: the not-so-RESTful pattern

– 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!

The “thing” retrieval pattern

R PUT

GET

POST 1 + POST 2 …. POST n

DELETE

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.

Resource naming structure pattern

Resource Name: /orders

Action URI Address Template HTTP Method

Create an order /orders POST

Get an order by given order id

./orders/{id} GET

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:\ota\data.txt -> returns the data for this resource -

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

There are 2 other HTTP methods which are a part of a URI: - HEAD: Retrieve a metadata-only representation - OPTIONS: Check which HTTP methods a particular resource supports 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.

HTTP HEAD and OPTIONS

R PUT

GET

POST

DELETE

HEAD

OPTIONS

Representations / content negotiation

GET /process/name

Web page with a form to start a new

process instance

List of process input parameters

Process metadata in JSON Basic textutal

description of the process

Images / Pictures

Content Type: text/plain

Content Type: text/html

Content Type: image/svg+xml

Content Type: application/json

Content Type: application/xml

• 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

API Versioning

PUBLISH / SUBSCRIBE

REST as a new connector

RPC: Remote Procedure Call

ESB: Enterprise Service Bus R R

REST / HTTP: Representational State Transfer Hypertext Transfer Protocol

R GET / PUT / POST / DELETE

R R

• Client waits until the process is done!

• Block the client until the execution is done

Working with resources in sync mode

/process

C R

POST /process

200 OK Execution done

DO SOMETHING ON THE SERVER

Note: blocking & non blocking requests are supported by HTTP

• Client starts a long running process

• Asynchronously process between the client and the started process

• Retrieve the current state of the started process

Working with resources in async mode

/process

C R

POST /process

200 OK

Note: blocking & non blocking requests are supported by HTTP

202 ACCEPTED Location: x

GET /process/x