Stefan Tilkov. Stefan Tilkov, innoq Deutschland GmbH REST Introduction

Transcription

1 Stefan Tilkov, in Deutschland GmbH REST Introduction (c) 2009 in Stefan Tilkov Geschäftsführer und Principal Consultant, in Deutschland GmbH Fokus auf SOA, Web-Services, REST SOA-Editor InfoQ.com Herausgeber SOA-Expertenwissen (mit Dr. Gernot Starke) Mitglied JSR 311 EG Autor REST und HTTP, dpunkt, Juli 2009 heise Developer podcast SoftwareArchitekTOUR (mit M. Stal, M. Völter, C. Weyer) (c) 2009 in

2 Beratungsunternehmen für Software- Architekturen ~50 Mitarbeiter in D (Ratingen, Darmstadt) und CH (Zürich) Strategische IT-Beratung, Architekturconsulting, Entwicklung Service-orientierte Architekturen (SOA) (WS-*, REST, OSS-Lösungen, Governance) Rationelle Software-Produktion (MDA, MDSD, Java EE, Ruby on Rails) in Deutschland GmbH in Schweiz GmbH Halskestraße 17 Gewerbestrasse 11 D Ratingen CH-6330 Cham Phone Phone [email protected] (c) 2009 in What is REST? (c) 2009 in

3 REST: An Architectural Style One of a number of architectural styles... described by Roy Fielding in his dissertation... defined via a set of constraints that have to be met... architectural principles underlying HTTP, defined a posteriori... with the Web as one particular instance See: (c) 2009 in REST: The Web Used Correctly A system or application architecture... that uses HTTP, URI and other Web standards correctly... is on the Web, not tunneled through it... also called WOA, ROA, RESTful HTTP (c) 2009 in

4 REST: XML without SOAP Send plain XML (w/o a SOAP Envelope) via HTTP... violating the Web as much as WS-*... preferably use GET to invoke methods... or tunnel everything through POST... commonly called POX (c) 2009 in Only option 1 is the ri one (because Roy said so) (c) 2009 in

5 But we ll go with option 2 (and equate REST with RESTful HTTP usage ) (c) 2009 in and avoid option 3 like the plague (c) 2009 in

6 REST Explained in 5 Easy Steps (c) 2009 in 1. Give Every Thing an ID (c) 2009 in

7 2. Link Things To Each Other <order self= > <amount>23</amount> <product ref= /> <customer ref= /> </order> (c) 2009 in 3. Use Standard Methods GET PUT POST DELETE retrieve information, possibly cached Update or create with known ID Create or append sub-resource (Logically) remove (c) 2009 in

8 4. Allow for Multiple Representations GET /customers/1234 Host: example.com Accept: application/vnd.mycompany.customer+xml <customer>...</customer> GET /customers/1234 Host: example.com Accept: text/x-vcard begin:vcard... end:vcard (c) 2009 in 5. Communicate Statelessly GET /customers/1234 Host: example.com Accept: application/vnd.mycompany.customer+xml <customer><order ref=./orders/46 </customer> shutdown update software replace hardware startup GET /customers/1234/orders/46 Host: example.com Accept: application/vnd.mycompany.order+xml time <order>...</order> (c) 2009 in

9 Consequences (c) 2009 in (c) 2009 in

10 Mapping Examples getfreetimeslots(person) GET /people/{id}/timeslots?state=free rejectapplication(application) performtariffcalculation(data) shiporder(id) shiporder(id) [variation] POST /rejections <application> <reason>unsuitable for us!</reason> POST /contracts Data Location: GET /contracts/4711/tariff Result PUT /orders/0815/status <status>shipped</status> POST /shipments Data Location: (c) 2009 in many many very few (one per service) (c) 2009 in

11 many very few (fixed) many (c) 2009 in REST and Web Services (c) 2009 in

12 Web Services Issues Web Services are Web in name only WS-* tends to ignore the web Abstractions leak, anyway Protocol independence is a bug, not a feature (c) 2009 in Tunneling Through POST (c) 2009 in

13 POST <soap:envelope xmlns:soap=" <soap:body> <deletecustomer xmlns=" <customerid>13</customerid> </ns:deletecustomer> </soap:body> </soap:envelope> Method ID Endpoint (c) 2009 in Endpoint? (c) 2009 in

14 (c) 2009 in (c) 2009 in

15 Web Services OrderManagementService + getorders() + submitorder() + getorderdetails() + getordersforcustomers() + updateorder() + addorderitem() + cancelorder() + cancelallorders() CustomerManagementService + getcustomers() + addcustomer() + getcustomerdetails() + updatecustomer() + deletecustomer() + deleteallcustomers() A separate interface (façade) for each purpose As known CORBA, DCOM, RMI/EJB Often used for SOA ( CORBA w/ angle brackets) Application-specific protocol (c) 2009 in Contribution to the Net s 2 URLs Value method POST (c) 2009 in

16 REST Approach «interface» Resource GET PUT POST DELETE /orders GET - list all orders PUT - unused POST - add a new order DELETE - cancel all orders /orders/{id} GET - get order details PUT - update order POST - add item DELETE - cancel order /customers GET - list all customers PUT - unused POST - add new customer DELETE - delete all customers /customers/{id} GET - get customer details PUT - update customer POST - unused DELETE - delete customer A single generic (uniform) interface for everything Generic verbs mapped to resource semantics A standard application protocol (e.g. HTTP) /customers/{id}/orders GET - get all orders for customer PUT - unused POST - add order DELETE - cancel all customer orders (c) 2009 in Contribution to the Net s Value Millions of URLs every customer every order 4-6 supported methods per resource GET, PUT, POST, DELETE, OPTIONS, HEAD Cacheable, addressable, linkable,... (c) 2009 in

17 (c) 2009 in Why You Should Care (c) 2009 in (c) 2009 in in in

18 My Internet is bigger than your enterprise. (c) 2009 in We ve been there before (c) 2009 in

19 (c) 2009 in Unlock information as resources VersicherungX (c) 2009 in

20 Q&A Stefan Tilkov Phone: (c) 2009 in