Von HTTP Interfaces zu RESTful Web Services (DevConHH 2012-09-08)

Presentation (German) given at Developer Conference Hamburg 2012 in Hamburg, Germany

Transcript

1. VON HTTP INTERFACES ZU RESTFUL WEB SERVICES
2. David Zülke
3. http://en.wikipedia.org/wiki/File:München_Panorama.JPG
4. Partner
6. Lead Developer
8. @dzuelke
9. DIE GUTEN ALTEN ZEITEN Bevor REST en vogue war
10. http://www.acme.com/index.php?action=zomg&page=lol
11. aber dann kamen
12.  dis is srs SEO bsns
13. und sagten
14. NEIN NEIN NEIN NEIN DAS IST VERBOTEN
15. also mussten wir URLs “SEO friendly” gestalten
16. http://www.acme.com/zomg/lol
17. und dann geriet ALLES AUSSER KONTROLLE OH GOTT
18. weil keiner wusste, was er tat
19. http://acme.com/videos/latest/hamburgers
20. http://acme.com/search/lolcats/pictures/yes/1/200
21. :(
22. AUFSTIEG DER WEB SERVICES Ohai, I'm ur CEO, I canhaz SOAP API plz, today, kthx?
23. POST  /soapendpoint.php  HTTP/1.1 Host:  localhost Content-­‐Type:  text/xml;  charset=utf-­‐8 <?xml  version="1.0"  encoding="UTF-­‐8"?> <SOAP-­‐ENV:Envelope  xmlns:SOAP-­‐ENV="http://schemas.xmlsoap.org/soap/envelope/">    <SOAP-­‐ENV:Body>        <ns1:getProduct  xmlns:ns1="http://agavi.org/sampleapp">            <id>123456</id>        </ns1:getProduct>    </SOAP-­‐ENV:Body> </SOAP-­‐ENV:Envelope> HTTP/1.1  200  OK Content-­‐Type:  text/xml;  charset=utf-­‐8 <?xml  version="1.0"  encoding="UTF-­‐8"?> <SOAP-­‐ENV:Envelope  xmlns:SOAP-­‐ENV="http://schemas.xmlsoap.org/soap/envelope/">    <SOAP-­‐ENV:Body>        <ns1:getProductResponse  xmlns:ns1="http://agavi.org/sampleapp">            <product>                <id>123456</id>                <name>Red  Stapler</name>                <price>3.14</price>            </product>        </ns1:getProductResponse>    </SOAP-­‐ENV:Body> </SOAP-­‐ENV:Envelope>
24. POST  /soapendpoint.php  HTTP/1.1 Host:  localhost Content-­‐Type:  text/xml;  charset=utf-­‐8 <?xml  version="1.0"  encoding="UTF-­‐8"?> <SOAP-­‐ENV:Envelope  xmlns:SOAP-­‐ENV="http://schemas.xmlsoap.org/soap/envelope/">    <SOAP-­‐ENV:Body>        <ns1:getProduct  xmlns:ns1="http://agavi.org/sampleapp">            <id>987654</id>        </ns1:getProduct>    </SOAP-­‐ENV:Body> </SOAP-­‐ENV:Envelope> HTTP/1.1  500  Internal  Service  Error Content-­‐Type:  text/xml;  charset=utf-­‐8 <?xml  version="1.0"  encoding="UTF-­‐8"?> <SOAP-­‐ENV:Envelope  xmlns:SOAP-­‐ENV="http://schemas.xmlsoap.org/soap/envelope/">    <SOAP-­‐ENV:Body>        <SOAP-­‐ENV:Fault>            <faultcode>SOAP-­‐ENV:Server</faultcode>            <faultstring>Unknown  Product  </faultstring>        </SOAP-­‐ENV:Fault>    </SOAP-­‐ENV:Body> </SOAP-­‐ENV:Envelope>
25. SOAP suckt, hat jeder gesagt
26. bauen wir doch APIs ohne den ganzen Schrott, hieß es dann
27. zum Beispiel: die http://joind.in/ API
28. POST  /api/talk  HTTP/1.1 Host:  joind.in Content-­‐Type:  text/xml;  charset=utf-­‐8 <?xml  version="1.0"  encoding="UTF-­‐8"?> <request>                <auth>                                <user>Chuck  Norris</user>                                <pass>roundhousekick</pass>                </auth>                <action  type="getdetail">                                <talk_id>42</talk_id>                </action> </request> HTTP/1.1  200  OK Content-­‐Type:  text/xml;  charset=utf-­‐8 <?xml  version="1.0"  encoding="UTF-­‐8"?> <response>   <item>     <talk_title>My  Test  Talk</talk_title>     <talk_desc>This  is  a  sample  talk  description</talk_desc>     <ID>42</ID>   </item> </response>
29. WAS HIER NICHT PASST • Immer ein POST • Verwendet nicht HTTP-basierte Authentication • Aufzurufende Operation ("getdetail") steckt im Request Body • Nichts ist out of the Box cachebar • Alles geht durch einen Endpoint (z.B. /api/talks für Talks)
30. Level 0 im Richardson Maturity Model: Plain Old XML Over The Wire im RPC-Stil
31. kleine Verbesserung: eine URI für jede Ressource “ “
32. das wäre Level 1 in Richardson's Maturity Model
33. Level 0 und Level 1 sind die Büchse der Pandora. Benutze sie nicht. Niemals.
34. DANN KAM ROY FIELDING und gab uns REST
35. das war klasse
36. weil jeder sagen konnte
37.  I haz REST nao
38. auch wenn es in Wirklichkeit
39. gelogen war
40. REST Akronühühühühüm?
41. REpresentational State Transfer
42. Roy Thomas Fielding: Architectural styles and the design of network based software architectures.
43. • Client-Server • Stateless • Cacheable • Layered System • Code on Demand (optional) • Uniform Interface REST CONSTRAINTS
44. • Eine URL identifiziert eine Resource • Methods führen Operations auf Resources aus • Die Operation ist implizit und nicht Teil der URL • Ein Hypermedia Format repräsentiert die Daten • Link relations dienen zur Navigation durch einen Service UNIFORM INTERFACE
45. eine Webseite is nicht eine Resource
46. sondern eine (vollständige) Representation einer Resource
47. GET  /products/  HTTP/1.1 Host:  acme.com Accept:  application/json HTTP/1.1  200  OK Content-­‐Type:  application/json;  charset=utf-­‐8 Allow:  GET,  POST [    {        id:  1234,        name:  "Red  Stapler",        price:  3.14,        location:  "http://acme.com/products/1234"    } ] JSON, BITTE
48. GET  /products/  HTTP/1.1 Host:  acme.com Accept:  application/xml HTTP/1.1  200  OK Content-­‐Type:  application/xml;  charset=utf-­‐8 Allow:  GET,  POST <?xml  version="1.0"  encoding="utf-­‐8"?> <products  xmlns="urn:com.acme.products"  xmlns:xl="http://www.w3.org/1999/xlink">    <product  id="1234"  xl:type="simple"  xl:href="http://acme.com/products/1234">        <name>Red  Stapler</name>        <price  currency="EUR">3.14</price>    </product> </products> XML, BITTE
49. beides keine Hypermedia-Formate!
50. (die gibt’s später)
51. GET  /products/  HTTP/1.1 Host:  acme.com Accept:  application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,*/*;q=0.5 User-­‐Agent:  Mozilla/5.0  (Macintosh;  U;  Intel  Mac  OS  X  10_5_8;  en-­‐us)  AppleWebKit… HTTP/1.1  200  OK Content-­‐Type:  text/html;  charset=utf-­‐8 Allow:  GET,  POST <html  lang="en">    <head>        <meta  http-­‐equiv="Content-­‐Type"  content="text/html;  charset=UTF-­‐8"></meta>        <title>ACME  Inc.  Products</title>    </head>    <body>        <h1>Our  Incredible  Products</h1>        <ul  id="products">            <li><a  href="http://acme.com/products/1234">Red  Stapler</a>  (€3.14)</li>        </ul>    </body> </html> HTML, BITTE
52. KAPITEL EINS Design von HTTP-Schnittstellen
53. ERST: RESOURCES DEFINIEREN Ein guter Ansatz: den URLs etwas Struktur verpassen
54. SCHLECHTE URLS • http://www.acme.com/product/ • http://www.acme.com/product/filter/cats/desc • http://www.acme.com/product/1234 • http://www.acme.com/photos/product/1234 • http://www.acme.com/photos/product/1234/new • http://www.acme.com/photos/product/1234/5678 WTF? photo oder product ID? neues was?
55. GUTE URLS • http://www.acme.com/products/ • http://www.acme.com/products/?filter=cats&sort=desc • http://www.acme.com/products/1234 • http://www.acme.com/products/1234/photos/ • http://www.acme.com/products/1234/photos/?sort=latest • http://www.acme.com/products/1234/photos/5678 Liste von Produkten Filtern über Query Einzelnes Produkt Fotos dazu
56. und gleich mal vorweggenommen
57. in einem wirklich RESTful Interface sind die URLs egal
58. lohnt sich aber dennoch, damit man in Ressourcen denkt
59. DANN: RESOURCES NUTZEN CRUD, fast jedenfalls
60. COLLECTION OPERATIONS • http://www.acme.com/products/ • GET um eine Liste von Produkten zu holen • POST um ein neues Produkt zu erzeugen • gibt zurück • 201 Created • Location: http://www.acme.com/products/1235
61. ITEM OPERATIONS • http://www.acme.com/products/1234 • GET um zu holen • PUT um zu aktualisieren • DELETE um zu, richtig geraten, löschen
62. and immer dran denken
63. Cookies: blöder Hack und nicht OMNOM für Maschinen
64. Jetzt sind wir bei Level 2 im RMM
65. RMM LEVEL 2 • HTTP-Verben benutzen • GET (safe und idempotent) • POST (unsafe, nicht idempotent) • PUT & DELETE (unsafe, idempotent) • HTTP Status Codes als Signal für Ergebnis einer Operation • z.B. HTTP/1.1 409 Conflict
66. DIE TWITTER API Nicht RESTful, und nicht mal HTTP richtig benutzt :(
67. wir schauen hier nicht einmal die RESTfulness an
68. sondern betrachten Twitter’s API nur aus Sicht von HTTP
69. AKTUELLER STAND • GET http://api.twitter.com/1/statuses/show/12345.json • POST http://api.twitter.com/1/statuses/update.json • DELETE http://api.twitter.com/1/statuses/destroy/12345.json • GET http://api.twitter.com/1/statuses/retweets/12345.json • PUT http://api.twitter.com/1/statuses/retweet/12345.json Erlaubt keinen Accept Header Wieso ein PUT? Wieso verschiedene? Zum Auth’d User! “DELETE destroy”, oda was krass?
70. WÄRE SO VIEL EINFACHER... • http://twitter.com/username/statuses/ • POST um einen neuen Tweet zu erzeugen • http://twitter.com/username/statuses/12345 • DELETE löscht (PUT könnte man für Änderungen nutzen) • http://twitter.com/username/statuses/12345/retweets/ • POST erzeugt einen neuen Retweet
71. DENKPAUSE Was ist der wichtigste Grund für den Erfolg des Web?
72. WWW
73. erstes System zum Datenaustausch
74. planetarer Skala
77. wie ist das möglich?
78. Hyperlinks!
79. kein tight coupling
80. sondern loosely coupled by design!
81. keine Benachrichtigungsinfrastruktur
82. keine Abhängigkeiten zwischen verlinkten Seiten
83. HTTP/1.1 404 Not Found
84. embraces failure
85. mehr Information != mehr Reibung
86. keine Grenze der Skalierbarkeit
87. WWW ist protokoll-zentrisch
88. KAPITEL ZWEI RESTful Services mit Hypermedia
89. DAS UNIFORM INTERFACE • Identification of Resources (durch URIs) • Representations sind konzeptuell davon lösgelöst! • Manipulation mittels Representations (die ja vollständig sind) • Self-Descriptive Messages (mit allen nötigen Informationen) • Hypermedia As The Engine Of Application State ("HATEOAS") ohne HATEOAS ist es kein REST
90. HATEOAS Das fehlende Teilchen im Puzzle
91. EIN LETZTES STÜCK FEHLT • Wie weiss ein Client, was mit einer Representation zu tun ist? • Wie geht er zum “nächsten Schritt”? • Wo legt er eine neue Ressource an? • Wo ist der Vertrag für den Service?
92. HYPERMEDIA AS THE ENGINE OF APPLICATION STATE • Clients nutzen Links, um Operationen/Locations zu entdecken • Per Link Relations werden die möglichen Optionen gefunden • Clients müssen URLs nicht vorher kennen und generieren • Der Workflow einer Anwendung wird flexibel • Der Hypermedia-Typ kann bei Bedarf versioniert werden • Änderungen am Server führen nicht mehr zu kaputten Clients
93. (X)HTML und Atom sind Hypermedia-Formate
94. oder man baut einfach selber eins...
95. GET  /products/1234  HTTP/1.1 Host:  acme.com Accept:  application/vnd.com.acme.shop+xml HTTP/1.1  200  OK Content-­‐Type:  application/vnd.come.acme.shop+xml;  charset=utf-­‐8 Allow:  GET,  PUT,  DELETE <?xml  version="1.0"  encoding="utf-­‐8"?> <product  xmlns="urn:com.acme.prods"  xmlns:atom="http://www.w3.org/2005/Atom">    <id>1234</id>    <name>Red  Stapler</name>    <price  currency="EUR">3.14</price>    <atom:link  rel="payment"  type="application/vnd.com.acme.shop+xml"                          href="http://acme.com/products/1234/payment"/> </product> Link-Elemente sind von Atom recyclen Bedeutung definiert in der IANA Link Relations Liste EIN EIGENER MEDIA TYPE Hilfestellung für Clients
96. bääääm, RMM Level 3
97. XML ist super für Hypermedia-Formate
98. (Attribute, Namespaces, Dokumentmodell, Streaming, …)
99. mit JSON ist das schwieriger
100. (Tight Coupling, Struktur-Änderungen brechen Clients)
101. <?xml  version="1.0"  encoding="utf-­‐8"?> <product  xmlns="urn:com.acme.prods"  xmlns:atom="http://www.w3.org/2005/xlink">    <id>1234</id>    <name>Red  Stapler</name>    <atom:link  rel="payment"  type="application/com.acme.shop+xml"                          href="http://acme.com/products/1234/payment"/>    <price>3.14</price> </product> {    id:  1234,    name:  "Red  Stapler",    links:  [        {            rel:  "payment",            type:  "application/vnd.com.acme.shop+json",            href:  "http://acme.com/products/1234/payment"        }    ],    price:  3.14 } XML VERSUS JSON
102. <?xml  version="1.0"  encoding="utf-­‐8"?> <product  xmlns="urn:com.acme.prods"  xmlns:atom="http://www.w3.org/2005/xlink">    <id>1234</id>    <name>Red  Stapler</name>    <atom:link  rel="payment"  type="application/com.acme.shop+xml"                          href="http://acme.com/products/1234/payment"/>    <price  currency="EUR">3.14</price> </product> {    id:  1234,    name:  "Red  Stapler",    links:  [        {            rel:  "payment",            type:  "application/vnd.com.acme.shop+json",            href:  "http://acme.com/products/1234/payment"        }    ],    price:  {        amount:  3.14,        currency:  "EUR"    } } XML VERSUS JSON Ändert nicht den Inhalt des Elements Float zu Object: Breaking Change
103. JSON-Formate sind schwierig zu erweitern
104. <?xml  version="1.0"  encoding="utf-­‐8"?> <products  xmlns="http://acme.com/shop/products">    <product  id="123">        <name>Bacon</name>        <price>5.99</price>    </product> </products>
105. <?xml  version="1.0"  encoding="utf-­‐8"?> <products  xmlns="http://acme.com/shop/products">    <product  id="123">        <name>Bacon</name>        <price>5.99</price>        OMNOMNOM  Bacon    </product> </products>
106. <?xml  version="1.0"  encoding="utf-­‐8"?> <products  xmlns="http://acme.com/shop/products">    <product  id="123">        <name>Bacon</name>        <price>5.99</price>        <price  currency="EUR">4.49</price>    </product> </products>
107. <?xml  version="1.0"  encoding="utf-­‐8"?> <products  xmlns="http://acme.com/shop/products">    <product  id="123">        <name  xml:lang="en">Bacon</name>        <name  xml:lang="de">Speck</name>        <price>5.99</price>    </product> </products>
108. <?xml  version="1.0"  encoding="utf-­‐8"?> <products  xmlns="http://acme.com/shop/products">    <product  id="123">        <name  xml:lang="en">Bacon</name>        <name  xml:lang="de">Speck</name>        <price>5.99</price>        <link  rel="category"  href="..."  />    </product> </products>
109. und merke
110. ohne Hypermedia ist ein HTTP Interface nicht RESTful
111. aber das macht ja nichts und manchmal geht es gar nicht anders
112. (CouchDB oder S3 können z.B. niemals RESTful werden)
113. verkneift euch nur, es "REST API" zu nennen :)
114. ein gutes Hypermedia-Beispiel: die Lovefilm API
115. <?xml  version="1.0"  encoding="utf-­‐8"  standalone="yes"?> <search>    <total_results>6</total_results>    <items_per_page>1</items_per_page>    <start_index>1</start_index>    <link  href="http://openapi.lovefilm.com/catalog/games?start_index=1&amp;items_per_page=1&amp;term=old"                rel="self"  title="self"/>    <link  href="http://openapi.lovefilm.com/catalog/games?start_index=2&amp;items_per_page=1&amp;term=old"                rel="next"  title="next"/>    <link  href="http://openapi.lovefilm.com/catalog/games?start_index=6&amp;items_per_page=1&amp;term=old"                rel="last"  title="last"/>    <catalog_title>        <can_rent>true</can_rent>        <release_date>2003-­‐09-­‐12</release_date>        <title  full="Star  Wars:  Knights  of  the  Old  Republic"  clean="Star  Wars:  Knights  of  the  Old  Republic"/>        <id>http://openapi.lovefilm.com/catalog/title/59643</id>        <adult>false</adult>        <number_of_ratings>574</number_of_ratings>        <rating>4</rating>        <category  scheme="http://openapi.lovefilm.com/categories/catalog"  term="games"/>        <category  scheme="http://openapi.lovefilm.com/categories/format"  term="Xbox"/>        <category  scheme="http://openapi.lovefilm.com/categories/genres"  term="Adventure"/>        <category  scheme="http://openapi.lovefilm.com/categories/genres"  term="Role-­‐playing"/>        <category  scheme="http://openapi.lovefilm.com/categories/certificates/bbfc"  term="TBC"/>        <link  href="http://openapi.lovefilm.com/catalog/title/59643/synopsis"                    rel="http://schemas.lovefilm.com/synopsis"  title="synopsis"/>        <link  href="http://openapi.lovefilm.com/catalog/title/59643/reviews"                    rel="http://schemas.lovefilm.com/reviews"  title="reviews"/>        <link  href="http://www.lovefilm.com/product/59643-­‐Star-­‐Wars-­‐Knights-­‐of-­‐the-­‐Old-­‐Republic.html?cid=LFAPI"                    rel="alternate"  title="web  page"/>    </catalog_title> </search>
116. GEHT ABER NOCH BESSER • Verwendet den generischen application/xml Media Type • Sollte ein spezieller sein, und dieser sollte auch in einem “type” Attribut auf jedem Element vermerkt werden • Sollte XML-Namespaces für das Wurzelelement vergeben, für jeden Typen einen anderen (z.B. “urn:com.lovefilm.api.item”, “urn:com.lovefilm.api.searchresult” und so weiter) • Damit kann Client-Code leicht den Dokumenttyp erkennen
117. noch eine schöne RESTful API: Huddle
118. <document    xmlns="http://schema.huddle.net/2011/02/"    title="TPS  report  May  2010"    description="relentlessly  mundane  and  enervating.">        <link  rel="self"  href="..."  />    <link  rel="parent"  href="..."  title="..."/>    <link  rel="edit"  href="..."  />    <link  rel="delete"  href="..."  />    <link  rel="content"  href="..."  title="..."  type="..."  />    <link  rel="thumb"  href="..."  />    <link  rel="version-­‐history"  href="..."  />    <link  rel="create-­‐version"  href="..."  />    <link  rel="comments"  href="..."  />        <actor  name="Peter  Gibson"  rel="owner">        <link  rel="self"  href="..."  />        <link  rel="avatar"  href="..."  type="image/jpg"  />        <link  rel="alternate"  href="..."  type="text/html"  />    </actor>        <actor  name="Barry  Potter"  rel="updated-­‐by">        <link  rel="self"  href="..."  />        <link  rel="avatar"  href="..."  type="image/jpg"  />        <link  rel="alternate"  href="..."  type="text/html"  />    </actor>        <size>19475</size>        <version>98</version>    <created>2007-­‐10-­‐10T09:02:17Z</created>    <updated>2011-­‐10-­‐10T09:02:17Z</updated>    <processingStatus>Complete</processingStatus>    <views>9</views> </document>
119. GEHT AUCH NOCH BESER • Viele rels wie “thumb” or “avatar” sind nicht in der IANA registry (http://www.iana.org/assignments/link-relations) gelistet • Risiko von Kollisionen oder Mehrdeutigkeiten; statt dessen sind Identifier wie “http://rels.huddle.net/thumb” besser • Alle Elemente in einem riesen XML-Schema und Namespace • Clients können Dokumenttyp nicht am Root-Tag erkennen • Ein großes Schema ist meist schwieriger zu erweitern
120. API VERSIONING Media Types To The Rescue!
121. Wieso nicht api.myservice.com/v1/foo/bar? und dann api.myservice.com/v2/foo/bar?
122. unterschiedliche URLs heißt: verschiedene Resources!
123. außerdem möchten Maschinen ja auch Bookmarks nutzen
124. GET  /products/1234  HTTP/1.1 Host:  acme.com Accept:  application/vnd.com.myservice+xml HTTP/1.1  200  OK Content-­‐Type:  application/vnd.com.myservice+xml;  charset=utf-­‐8 Allow:  GET,  PUT,  DELETE <?xml  version="1.0"  encoding="utf-­‐8"?> <product  xmlns="urn:com.acme.products"  xmlns:xl="http://www.w3.org/1999/xlink"                    id="1234"  xl:type="simple"  xl:href="http://acme.com/products/1234">    <name>Red  Stapler</name>    <price  currency="EUR">3.14</price> </product> API VERSION 1
125. (einige Zeit vergeht...)
126. GET  /products/1234  HTTP/1.1 Host:  acme.com Accept:  application/vnd.com.myservice+xml HTTP/1.1  404  Not  Found Content-­‐Type:  application/vnd.com.myservice+xml;  charset=utf-­‐8 API VERSION 1
127. inzwischen bietet der Server eine neue API-Version: mit Verfügbarkeits-Status (Breaking Change!)
128. GET  /products/1234  HTTP/1.1 Host:  acme.com Accept:  application/vnd.com.myservice.v2+xml HTTP/1.1  200  OK Content-­‐Type:  application/vnd.com.myservice.v2+xml;  charset=utf-­‐8 Allow:  GET,  PUT,  DELETE <?xml  version="1.0"  encoding="utf-­‐8"?> <product  xmlns="urn:com.acme.products"  xmlns:xl="http://www.w3.org/1999/xlink"                  id="1234"  xl:type="simple"  xl:href="http://acme.com/products/1234">    <name>Red  Stapler</name>    <price  currency="EUR">3.14</price>    <availability>false</availability> </product> API VERSION 2
129. Protocol Upgrades mit Version in der URL unmöglich!
130. oder was wenn jede Installation von phpBB eine API hat?
131. mit API-Version in der URL müssen Clients regexen
132. http://sharksforum.org/community/api/v1/threads/102152
133. http://forum.sharksforum.org/api/v1/threads/102152
134. ja pfui
135. oder was wenn ein anderer Hersteller die API nutzen will?
136. dann müssen die auch “/api/v1/” in allen URLs verwenden
137. URI-basierte Versionierung ruiniert Interoperabilität
138. NUN STELLT SICH DIE FRAGE: Was genau bringt das alles?
139. DIE VORZÜGE VON REST • Leicht zu erweitern: neue Elemente oder Funktionen brechen nicht BC • Leicht zu lernen: man kann den Service “ersurfen” • Leicht zu skalieren: wächst gut mit der Anzahl Clients, Server und Funktionen • Leicht umzusetzen: einfach auf HTTP aufsetzen, fertig! • Authentication & TLS • Caching & Load Balancing • Conditional Requests • Content Negotiation
140. aber...
141. Moment, sagt jetzt einer
142. ein einfacher HTTP-basierter Dienst tut es doch auch
143. REST muss doch mehr bieten als nur Erweiterbarkeit?
144. nope
145. "REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design." Roy Fielding
146. "Most of REST's constraints are focused on preserving independent evolvability over time, which is only measurable on the scale of years. Most developers simply don't care what happens to their product years after it is deployed, or at least they expect to be around to rewrite it when such change occurs." Roy Fielding
147. LESESTOFF • Ryan Tomayko How I Explained REST to my Wife http://tomayko.com/writings/rest-to-my-wife • Jim Webber, Savas Parastatidis & Ian Robinson How to GET a Cup of Coffee http://www.infoq.com/articles/webber-rest-workflow • Roy Thomas Fielding Architectural Styles and the Design of Network-based Software Architectures http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
148. BÜCHER • Jim Webber, Savas Parastatidis, Ian Robinson REST in Practice ISBN: 978-0596805821 • Subbu Allamaraju RESTful Web Services Cookbook ISBN: 978-0596801687 • Leonard Richardson, Sam Ruby RESTful Web Services ISBN: 978-0596529260
149. !e End
150. Fragen?
151. DANKE! Das war Von HTTP Interfaces zu RESTful Web Services von @dzuelke. E-Mails: david.zuelke@bitextender.com