Cesare Pautasso Erik Wilde
|
Introduction: This introduction presents the schedule, the tutorial presenters, and some background for the tutorial. Specifically, we briefly mention all the *OA terms that have been invented in recent years, such as SOA (Services), ROA (Resources), WOA (Web), SynOA (Syndication), and EOA (Event), and set them into context. Our main goal is to explain our notion of SOA for the purpose of this tutorial, and what we perceive as the core tasks when moving from SOA to REST. |
Introduction ( [intro.pdf]) |
[http://dret.net/biblio/reference/pau09a] |
Erik Wilde
|
What is REST?: Representational State Transfer (REST) is defined as an architectural style, which means that it is not a concrete systems architecture, but instead a set of constraints that are applied when designing a systems architecture. We briefly discuss these constraints, but then focus on explaining how the Web is one such systems architecture that implements REST. In particular, the mechanisms of the Uniform Resource Identifiers (URIs), the Hypertext Transfer Protocol (HTTP), media types, and markup languages such as the Hypertext Markup Language (HTML) and the Extensible Markup Language (XML). We also introduce Atom and the Atom Publishing Protocol (AtomPub) as two established ways on how RESTful services are already provided and used on today's Web. |
REST ( [rest.pdf]) |
[http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm] · [http://portal.acm.org/citation.cfm?doid=337180.337228] |
Cesare Pautasso
|
RESTful Service Design: REST is simple to define, but understanding how to apply it to design RESTful services is more difficult. The goal of this part of the tutorial is to present the main design elements of a RESTful architecture and introduce a design methodology for RESTful services. A selection of useful patterns and anti-patterns will be discussed with some examples that will be further developed in the practical part. |
Service Design |
[http://oreilly.com/catalog/9780596529260/] |
Cesare Pautasso
|
REST vs. WS-* Comparison: In this part we summarize the WS-* vs. REST debate by giving a quantitative technical comparison based on architectural principles and decisions. We show that the two approaches differ in the number of architectural decisions that must be made and in the number of available alternatives. This discrepancy between freedom-from-choice and freedom-of-choice explains the complexity difference perceived. However, we also show that there are significant differences in the consequences of certain decisions in terms of resulting development and maintenance costs. The comparison helps technical decision makers to assess the two technologies more objectively and select the one that best fits their needs: REST is well suited for basic, ad hoc integration scenarios, WS-* is more flexible and addresses advanced quality of service requirements commonly occurring in enterprise computing. |
REST vs. WS-* |
[http://www.jopera.org/docs/publications/2008/restws] |
Erik Wilde
|
REST in Practice: REST's level of abstraction and its simplicity as a small set of constraints can make it hard to get a grasp on how it can be applied for real-world projects. This presentations introduces real-world REST by looking at how REST can be used by reusing existing RESTful designs in terms of representations and interaction protocols; Atom and the Atom Publishing Protocol (AtomPub) are used as examples for existing RESTful designs. In addition, we take a brief look at how to go beyond using these canned REST approaches, and how existing programming framework provide support for designing and implementing RESTful services. |
Practice ( [practice.pdf]) |
[http://atompub.org/rfc4287.html] · [http://atompub.org/rfc5032.html] · [http://validator.w3.org/feed/] |