REST 2015

Talk at W-JAX 2015 on what to know about REST in 2015

Transcript

1. REST 2015 W-JAX 2015 Silvia Schreier @aivlis_s
2. 15 years of REST — definitely no old hat but still the same questions
3. What is REST?
4. Academic point of view derivative of by “DSC_0575” Will Folsom (CC BY 2.0)
5. REST is an architectural style for distributed hypermedia systems
6. Architectural Style: set of constraints that induce certain properties
7. Why should I care? “Some architectural styles are often portrayed as “silver bullet” solutions for all forms of software. However, a good designer should select a style that matches the needs of the particular problem being solved.” — Roy Thomas Fielding
8. Properties Separation of concerns Portability Scalability Independent evolution Loose coupling Visibility Reliability Improved network efficiency User-perceived performance Simplicity Efficient large-grain data transfer System extensibility
9. Trade-offs Reduced control over application behavior Stale data Efficiency
10. How to REST in practice? derivative of by “A Nice Place To Sit” Richard Walker (CC BY 2.0)
11. Identify everything of interest derivative of by “Personal Income Taxes Ver8” Chris Potter (CC BY 2.0)
12. Make these resources accessible via URIs
13. Different formats and content negotiation
14. This should cover most of the read-only use cases of your interface.
15. How to modify data? Fixed set of operations: D E L E T E P U T P A T C H
16. What about creation?
17. Typical pattern P O S T / l i s t with new element’s data in body 2 0 1 C r e a t e d with L o c a t i o n header as response
18. Other operations? Accept Decline Apply for sth. Send
19. Step 1: nominalization Accept  create acceptance Decline  create declination Apply for sth.  create application Send  trigger sending
20. Step 2: match with HTTP verbs Create acceptance  P U T / t r i p s / 1 / a c c e p t a n c e Create declination  P U T / t r i p s / 2 / d e c l i n a t i o n with reason as body Create application  P O S T / t r i p s Trigger sending  P O S T / m e s s a g e / 1 / s e n d i n g
21. Status codes
22. GET http://erp.innoq.com/trips GET http://erp.innoq.com/selection?id=2 POST http://erp.innoq.com/receipts { amount: 30.25 , currency: "EUR" }
23. Statelessness
24. GET http://erp.innoq.com/trips GET http://erp.innoq.com/trips/2 POST http://erp.innoq.com/trips/2/receipts { amount: 30.25 , currency: "EUR" }
25. How do I know what to do and where to find what? derivative of by “Future Bangkok MRT Map (printed)” Oran Viriyincy (CC BY 2.0)
26. Why do search engines work?
27. Links derivative of by “directions“ Matthias Mueller (CC BY 2.0)
28. Problem: Hypermedia often used only for connecting data
29. Why do I know how to interact with web applications?
30. HTML Forms
31. That is HATEOAS: Hypermedia as the engine of application state
32. So HATEOAS is adding links and forms to the representations?
33. derivative of by “It's a No!” smlp.co.uk (CC BY 2.0)
34. Hypermedia is a client’s thing!
35. Most successful hypermedia client? derivative of by Andreas Praefcke (public domain) “Golden laurel wreath”
36. Browser features Hypermedia controls Content negotiation Status code handling, e.g., redirects and auth Caching Handling unknown elements Code on demand Bookmarks
37. derivative of by “Dreams & Reality - Masterpieces from Musee D'Orsay” Walter Lim (CC BY 2.0)
38. Typical so called “REST clients” tripList = get("http://erp.innoq.com/trips"); lastTrip = get("http://erp.innoq.com/trips/" + tripList.last.id); response = post("http://erp.innoq.com/trips", tripData); newTrip = get("http://erp.innoq.com/trips/" + response.id);
39. How to do better erpHome = get("http://erp.innoq.com"); trips = erpHome.followLink("trips"); lastTrip = trips.links("trip").last.follow(); response = erpHome.extractLink("trips").post(tripData); newTrip = response.headers("location").get();
40. How do the developers know what to do?
41. Déjà vu: REST documentation URI Method Meaning h t t p : / / e r p . c o m / v 1 / t r i p s P O S T create new trip h t t p : / / e r p . c o m / v 1 / t r i p s / { i d } G E T get trip details h t t p : / / e r p / v 1 / t r i p s / { i d } / r e c e i p t s G E T get list of the trip's receipts ... ... ...
42. Server vs. client developer documentation
43. Core elements of your interface: media types & link relations
44. Document the core elements of the interface
45. Connect documentation and application with hypermedia
46. Solution Documentation as additional resources Introduce documentation link relation Representations link to documentation Link header as an alternative Documentation links to link relations, media types and back to application
47. What about evolution?
48. Version number in the URI? derivative of by “DSC_1607” Justin Baeder (CC BY 2.0)
49. derivative of by “It's a No!” smlp.co.uk (CC BY 2.0)
50. Alternatives New resources Extendible formats New link relations New formats
51. Recap: Why should I use REST? Scalability Loose coupling Reliability Simplicity
52. What about the users? by “...next generation” zeitfaenger.at (CC BY 3.0)
53. Do not underestimate the web UI
54. Front-end architecture heavily influences your overall architecture
55. Sometimes it seems tedious but these stuff runs on more than one server platform!
56. Options for web UIs Component-based server frameworks e.g., Wicket, JSF Server-side MVC frameworks e.g., Spring MVC, Play, ASP.NET MVC Client-side MVC frameworks (SPA) & REST API e.g., AngularJS, Ember.js
57. Know and consider the (dis-)advantages of these options
58. SPA vs. server-side MVC (with content negotiation)
59. Is such an UI cool enough? derivative of by “#153 Sun-glasses” Mikael Miettinen (CC BY 2.0)
60. What is a modern web UI? Fast / immediate user feedback No full page reload Runs on different clients Works even with bad network connection Offline capability Accessibility
61. As an architect I want more Maintainability Robustness Seperation of concerns No duplication of logic Accessible by search engines Security (we will talk about that later)
62. Idea: Resource-oriented client architecture
63. ROCA RESTful server Business logic only on the server Best experience for all clients Understand the 3 piles of the web Use them as they were meant  Separation of concerns http://roca-style.org/
64. What else is in the news? derivative of by “Newspapers B&W (5)” Jon S (CC BY 2.0)
65. New for HTTP/1.1 RFCs
66. HTTP/1.x Problems TCP Connection-Overhead Handshake Slow-start Verbosity  Not efficient for fine-grained requests
67. HTTP/2 Multiplexing Correlation between Request/Response Header compression Binary protocol  HTTP/1.1 hacks no longer necessary
68. Last but not least: security derivative of by “Security” David Goehring (CC BY 2.0)
69. Authentication Keep it as simple as possible: Basic Auth + SSL Cookie-based authentication TLS certificates Single sign-on
70. SSO is not for free Complexity Many different options Token lifetime Redirect-based SSO causes problems with POST
71. derivative of by “Authorized Entry Only” Christina Weese (CC BY 2.0)
72. OAuth 2 Authorization framework not a protocol Only based on TLS Naive implementations are probably insecure Many open details Incompatible implementations
73. OAuth 2 + Identity layer = OpenID Connect
74. Now my app is secure?
75. Never trust a stranger derivative of by “A Stranger” Alyssa L. Miller (CC BY 2.0)
76. Things you should care about : Cross-Site Request Forgery (CSRF) Cross-Origin Resource Sharing (CORS) Code injection Signatures and encryption ... Open Web Application Security Project checklist
77. Summary REST: Which constraint induces which property? Documentation influcences your architecture Frontend architecture is a serious topic ROCA vs. SPA HTTP/2 is on its way Security in distributed systems is no free lunch
78. Thank you! Questions? Silvia Schreier silvia.schreier@innoq.com @aivlis_s http://innoq.com
79. More references (in German) (in German) Dissertation by Roy Thomas Fielding http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm REST APIs must be hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven REST und HTTP http://rest-http.info/ Podcast zu „REST und HTTP“ https://www.innoq.com/de/podcast/022-rest-und-http/ Web architecture at innoQ https://www.innoq.com/de/topics/web/ Progressive Enhancement https://www.innoq.com/en/talks/2015/06/mediterraneajas-progressive-enhancement-talk/ Developing Modular JavaScript Components http://www.infoq.com/articles/modular-javascript http2 explained http://daniel.haxx.se/http2/ OAuth2 und OpenID Connect https://www.innoq.com/de/talks/2015/04/oauth2-openid-connect-jax2015/ OAuth 2.0 and the Road to Hell http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ OAuth 2 Simplified http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified