2012 North American Advisory Forum (Miami  Florida  April 2012)                       PANEL PRESENTATIONOpenTravel and R...
2012 North American Advisory Forum (Miami  Florida  April 2012)                    Panel ParticipantsRONI SCHUETZ, Enter...
OPENTRAVELAND RESTFUL RESOURCES Championed by the Web communityRoni Schuetz,Enterprise Software ArchitectOpenTravel Adviso...
API Statshttp://www.programmableweb.com/apis
Representational State Transfer• Fielding captured his interpretation of the  WWW architecture in his 2000 thesis• Adopted...
Do we need REST?• We need a natural way to model resource-based  services: that’s why we are here: OpenTravel!• We should ...
REST in one slide• Resources expose their data and functionality through resources  identified by a unique URI• Uniform In...
REST Principles• Resource based - not service based• Addressability - name everything that matters• Statelessness - no sta...
Resource based• A resource is something “interesting” in your system   – Can be anything      • Spreadsheet      • Printer...
HTTP based?• REST principles are not HTTP dependent• Typically REST should be implemented as an  HTTP architectural style•...
RESTful Services best practices•   Representation agnostic•   Versioning•   Service Description•   Exception Handling•   S...
References & Resources•   http://www.xml.com/pub/a/2004/12/01/restful-web.html•   http://www.infoq.com/articles/webber-res...
GET vs. POST Retrieving Paradigm• To retrieve a “thing” from a Resource we have  2 options:  – The HTTP GET options:      ...
HTTP Sample for get / post  GET /index.html?userid=joe&password=guessme  HTTP/1.1 Host: www.mysite.com  User-Agent: Mozill...
The “thing” retrieval pattern                            PUT                                                              ...
PUT vs. POST Creation Paradigm• To create a new “thing” shall I use PUT or  POST?  There is a clear principle for this par...
Resource naming structure patternResource Name: /orders          Action             URI Address Template                  ...
HTTP status codes on a ResourceResource                 Method                  Status Code                    CRUD - Acti...
PUTHTTP HEAD and OPTIONS                                                                                OPTIONSThere are 2...
Representations / content negotiation  Web page with a                                       List of process input form to...
API Versioning• This concept makes it very easy to maintain  different versions:   –   GET /1.0/orders/ {id}   –   GET /1....
REST as a new connector RPC: Remote Procedure Call                               REST / HTTP:                             ...
Working with resources in sync mode                  /process                             • Client waits until the process...
Working with resources in async mode                    /process                               • Client starts a long runn...
Upcoming SlideShare
Loading in...5
×

OpenTravel Advisory Forum 2012 REST XML Resources

3,125

Published on

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.

Published in: Education, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,125
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
56
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

OpenTravel Advisory Forum 2012 REST XML Resources

  1. 1. 2012 North American Advisory Forum (Miami  Florida  April 2012) PANEL PRESENTATIONOpenTravel 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. 2. 2012 North American Advisory Forum (Miami  Florida  April 2012) Panel ParticipantsRONI 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, HomeAwaySTUART WALDRON, Information Technology Architect, Amtrak
  3. 3. OPENTRAVELAND RESTFUL RESOURCES Championed by the Web communityRoni Schuetz,Enterprise Software ArchitectOpenTravel Advisory ForumMiami, April 2012©2010 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change withoutnotice
  4. 4. API Statshttp://www.programmableweb.com/apis
  5. 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. 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. 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. 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. 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. 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. 11. RESTful Services best practices• Representation agnostic• Versioning• Service Description• Exception Handling• Security• Service Repository
  12. 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. 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. 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. 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. 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. 17. Resource naming structure patternResource Name: /orders Action URI Address Template HTTP MethodCreate an order /orders POSTGet an order by given ./orders/{id} GETorder idUpdate an order ./orders/{id} PUTDelete an order ./orders/{id} DELETEResource 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. 18. HTTP status codes on a ResourceResource 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, …. DeleteStatus Code Description200 OK201 Created204 No Content301 Moved Permanently400 Bad Request410 Gone500 Internal Server Error501 Not Implemented503 Service UnavailableStatus Code Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
  19. 19. PUTHTTP HEAD and OPTIONS OPTIONSThere 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 DELETEHEAD:- 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 resourcewithout fetching its entire representation. So we have the same functionality like a HTTP GET but nowthe call does not fetch data.OPTIONS:- The OPTIONS method lets the client to discover what its allowed to do to a resource. The response toan OPTIONS request contains the HTTP Allow header, which lays out the subset of the uniform interfacethis resource supports.E.g. : Allow: GET, HEADThat means that the client can send a GET and HEAD request to this resource but the resource does notsupport any other methods - effectively, this resource is read-only.
  20. 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. 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. 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. 23. Working with resources in sync mode /process • Client waits until the processC 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. 24. Working with resources in async mode /process • Client starts a long runningC 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×