Brian Sletten Bosatsu Consulting, Inc. brian@bosatsu.net
Brian Sletten Bosatsu Consulting, Inc. brian@bosatsu.net
Brian Sletten Bosatsu Consulting, Inc. brian@bosatsu.net
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Applied<br />
REST<br />
<strong>Brian</strong> <strong>Sletten</strong><br />
<strong>Bosatsu</strong> <strong>Consulting</strong>, <strong>Inc</strong>.<br />
<strong>brian@bosatsu</strong>.<strong>net</strong>
Speaker Qualifications<br />
Over 13 years of software development<br />
experience<br />
Has own software consulting company for<br />
design, mentoring, training and development<br />
Currently working in Semantic Web, AOP,<br />
Grid Computing, P2P and security consulting<br />
2
Agenda<br />
Why Do We Care?<br />
REST Concepts<br />
REST Examples<br />
REST Motivation<br />
Building RESTful Interfaces<br />
Conclusion<br />
3
Why Do<br />
We Care?
WS-Dissatisfaction<br />
“Conventional” Web Services are often<br />
too difficult for non-trivial tasks (real complexity)<br />
too complex for trivial tasks (artificial complexity)<br />
RPC-based Web Services are mythically<br />
interoperable and time/process coupled in<br />
painful ways<br />
5
What Makes SOAP Difficult?<br />
Will the real SOAP intended use please stand<br />
up?<br />
Remote Procedure Calls<br />
Application Protocols<br />
Tunneling using existing Application Protocols<br />
(HTTP)<br />
6
Security Abominations<br />
Tunneling SOAP through firewalls is a<br />
questionable practice<br />
HTTP is not a transport protocol!<br />
Intermediaries can only route to endpoints<br />
No actionable semantics in RPC interactions<br />
7
SOA<br />
Service-Oriented Architecture (SOA)<br />
An architectural style promoting loose<br />
coupling among software participants<br />
Companies have rigid definitions of what<br />
constitutes a SOA<br />
Must Publish/Find/Bind = UDDI/WSDL/SOAP?<br />
8
SOA What?<br />
SOAP 1.2 and Doc Lit are improvements, but<br />
are they necessary?<br />
What is the problem we are trying to solve?<br />
We already have an example of a scalable<br />
software architecture for <strong>net</strong>work applications<br />
9
Return of the Vendors<br />
Vendors are fine<br />
However, too many are trying to sell you the same<br />
thing repackaged without thinking about what we<br />
are trying to solve<br />
CORBA ORB and tools ✘<br />
EJB Container ✘<br />
SOA-complexity managing tools ✔<br />
10
If You Build It...<br />
...they will use REST<br />
Anecdotally, 85% of Amazon’s users choose REST<br />
over SOAP<br />
11
REST<br />
Concepts
What is REST?<br />
REpresentational State Transfer (REST)<br />
An architectural style based on certain<br />
constraints designed to elicit properties of<br />
scalability and extensibility<br />
An idealized notion of how the early Web<br />
should work<br />
Helped drive the way it eventually did work<br />
More than just URLs!<br />
13
Resource<br />
Anything that can be named/referred to<br />
Files<br />
Services<br />
Concepts<br />
What is returned can change over time<br />
Consider the “trunk” version of a file in Subversion<br />
14
Resource Abstraction<br />
Generality by allowing different types<br />
Static or Dynamic<br />
Flexibility through late binding negotiation of<br />
type<br />
Abstract references that do not necessarily<br />
need updating when the underlying format<br />
changes<br />
GIF->PNG<br />
15
Resource Identifier<br />
Means of naming a resource<br />
Standard syntax that allows various schemes<br />
Known as URIs (or IRIs)<br />
Orthogonal to satisfying the reference<br />
One of the main missing pieces of “normal”<br />
web services<br />
16
Representation<br />
A particular deferencing of a Resource<br />
Identifier to a Resource at a particular time<br />
Think the file “index.html” or<br />
“Today’s Slashdot Page”<br />
A byte-stream tagged with metadata<br />
Could change based on request or<br />
processing/display capabilities of client<br />
Firefox vs. WAP<br />
17
Resource/Representation<br />
Metadata<br />
Accompanies a Representation<br />
Allows intermediaries to make decisions (caching)<br />
Helps clients know how to display the Resource<br />
<strong>Inc</strong>ludes<br />
MIME Type<br />
Last modified date<br />
18
REST Verbs<br />
Design decision to minimize the breadth of<br />
the interface<br />
RPC is completely open-ended from an action<br />
perspective<br />
19
GET<br />
Retrieve a Resource<br />
20
POST<br />
Create a Resource<br />
21
PUT<br />
Update a Resource<br />
22
DELETE<br />
Remove a Resource<br />
23
REST<br />
Examples
Why Not Apache? Tomcat? IIS?<br />
Jetty?<br />
All of these web servers can certainly expose<br />
RESTful interfaces<br />
Once you look under the hood, however, it<br />
becomes more complicated<br />
25
NetKernel<br />
Ground up generalized architecture built<br />
around REST<br />
Microkernel maps requests for resources into<br />
the software components that will satisfy the<br />
requests<br />
Benefits from the architectural properties we<br />
have discussed<br />
26
RESTlet<br />
Lightweight Java-based REST framework<br />
Alternative API to Servlets for cleaner match<br />
to REST concepts<br />
Support for filters, authentication logging,<br />
blocking and non-blocking IO<br />
27
REST<br />
Motivation
The REST is History<br />
Concepts are based on Roy Fielding’s work<br />
- On his Ph.D. Thesis “Architectural Styles and the<br />
Design of Network-based Software Architectures”<br />
- On HTTP 1.0/1.1 Standards<br />
- On Apache, libwww and related projects<br />
29
Software Architecture<br />
“A software architecture is defined by a<br />
configuration of architectural elements —<br />
components, connectors, and data —<br />
constrained in their relationships in order to<br />
achieve a desired set of architectural<br />
properties.”<br />
-- R.F. Thesis<br />
30
Architectural Style<br />
“An architectural style is a coordinated set of<br />
architectural constraints that restricts the<br />
roles/features of architectural elements and<br />
the allowed relationships among those<br />
elements within any architecture that<br />
conforms to that style.”<br />
-- R.F. Thesis<br />
31
Architectural Effects<br />
Choice of a particular architectural style has<br />
consequences for how components<br />
communicate<br />
Affects overall growth potential and<br />
performance of a system<br />
32
Architectural Properties Of<br />
Interest<br />
Performance<br />
Scalability<br />
Generality<br />
Simplicity<br />
Modifiability<br />
33
REST Goals<br />
Provide architectural guidance<br />
Minimize latency of <strong>net</strong>work software<br />
applications<br />
Maximize component independence and<br />
scalability<br />
Support extensibility through small, welldefined<br />
abstract interfaces<br />
34
Client-Server<br />
Supports Separation of Concerns (SOC)<br />
UI code can be localized in client<br />
Backend logic can be localized in server<br />
(reused by different clients)<br />
35
Client-Server<br />
36
Stateless<br />
All parameters travel with request<br />
No session information maintained on server<br />
Improves scalability through load-balancing<br />
Improves visibility of intermediary processors<br />
37
Stateless Client-Server<br />
38
Replication<br />
Decentralization of data<br />
Can be wholly or partially copied around<br />
Improves accessibility and scalability<br />
Improves user perception of performance<br />
Introduces need to keep data in synch<br />
39
Cache<br />
Form of replication when external data set is<br />
too large to copy locally<br />
Results of individual requests can be<br />
captured and re-served later<br />
40
Uniform Interface<br />
Improves generality, simplicity and reusability<br />
Can cause performance issues when data<br />
needs conversion to/from standard formats but<br />
REST tries to optimize for average Web data<br />
types<br />
41
Stateless Client-Server w/ Cache<br />
and Uniform Interface<br />
42
Layered System<br />
Managed dependencies between layers<br />
Improved modifiability by compartmentalizing<br />
visibility to neighboring layers<br />
43
Layered Stateless Client-Server<br />
w/ Cache and Uniform Interface<br />
44
REST Properties<br />
Based on figure from R.F.’s thesis<br />
45
Building<br />
RESTful<br />
Interfaces
What is Controversial<br />
URI Opacity<br />
How much meaning should there be in<br />
URIs?<br />
How do naming schemes<br />
affect intermediary processing?<br />
make the Web brittle?<br />
differ by language context?<br />
47
tbl on URI Opacity<br />
“When you are not dereferencing<br />
you should not look at the<br />
contents of the URI string to gain<br />
other information.”<br />
http://www.w3.org/DesignIssues/Axioms.html<br />
http://www.flickr.com/photos/ajstarks/152558066/<br />
48
Roy on URI Opacity<br />
"REST does not require that a URI be opaque. The<br />
only place where the word opaque occurs in my<br />
dissertation is where I complain about the<br />
opaqueness of cookies. In fact, RESTful applications<br />
are, at all times, encouraged to use humanmeaningful,<br />
hierarchical identifiers in order to<br />
maximize the serendipitous use of the information<br />
beyond what is anticipated by the original<br />
application."<br />
http://tech.groups.yahoo.com/group/rest-discuss/<br />
message/3232<br />
49
UnREST<br />
REST is largely defined by a small number of semi-formal specifications, a larger<br />
number of secondary publications and writings, and the collected design notes,<br />
anecdotes, and essays of Tim Berners-Lee. Among these artifacts there are a<br />
number of contradictions, a number of ambiguities, and perhaps at least some<br />
assertions and principles which are not sufficiently supported. Where certain<br />
principles and assertions can be formalized and their observable impact quantifiably<br />
understood, REST is solid...<br />
My beef with the Opacity Axiom (hereafter, "the axiom") is that it (needlessly, IMHO)<br />
discards the important and useful concept of structured naming and semantically<br />
rich namespaces. In filesystems research and elsewhere over the last decade or<br />
two (described in slightly more detail in OpacityReconsidered) many researchers<br />
have recognized the power and utility gained by enriching the structure and<br />
semantics of names and namespaces. The Web, curiously, runs absolutely counter<br />
to this trend.<br />
--Jeff Bone<br />
(http://rest.blueoxen.<strong>net</strong>/cgi-bin/wiki.pl?OpacityMythsDebunked)<br />
50
Encoding Meaning in Structure<br />
Which is more meaningful? (To Whom?)<br />
http://www.bosatsu.<strong>net</strong>/talks/NFJS/2006/REST<br />
http://www.bosatsu.<strong>net</strong>/12123125231234123412<br />
51
Hierarchies<br />
http://www.bosatsu.<strong>net</strong>/talks/NFJS/2006/REST<br />
Organizational<br />
Temporal<br />
Topical ?<br />
52
Hierarchical + Non-Hierchical<br />
http://www.bosatsu.<strong>net</strong>/talks/NFJS/2006/REST/Reston<br />
Organizational<br />
Temporal<br />
Topical ?<br />
53
When You Aren’t Sure<br />
Use query strings for non hierarchicallyrelated<br />
attributes<br />
http://www.bosatsu.<strong>net</strong>/talks/NFJS/2006?talk=REST&location=Reston<br />
54
Pragmatic REST<br />
At a minimum, URIs must be able to be<br />
treated opaquely<br />
Hierarchical spaces are conveniently<br />
represented through the path portion of a URI<br />
Non-hierarchical attributes should be<br />
delegated to the query parameters<br />
55
What Isn’t Controversial<br />
Do not rely on sessions or other state at the<br />
application level<br />
Use nouns, not verbs<br />
Don’t abuse GET!<br />
No side effects<br />
Don’t abuse POST!<br />
Limit use to creation, not conversational GET<br />
56
Real World Examples<br />
Amazon<br />
http://www.amazon.com/gp/aws/landing.html<br />
eBay<br />
http://developer.ebay.com/developercenter/rest<br />
Yahoo!<br />
http://developer.yahoo.com<br />
Bloglines<br />
Atom<br />
Ruby on Rails<br />
(1.2)<br />
http://bloglines.com/services/<br />
http://tools.ietf.org/wg/atompub/draft-ietfatompub-protocol/<br />
http://www.rubyonrails.org/<br />
57
Conclusion
Open Issues<br />
Describing RESTful services to clients<br />
Publishing metadata about RESTful services<br />
Transactions<br />
Conversational State<br />
59
Main Points<br />
REST may not be the only answer, but it is<br />
often the more straightforward answer<br />
REST is more than using URLs to access<br />
web services<br />
It is the deliberate application of architectural<br />
constraints to elicit the properties of scalability,<br />
simplicity, modifiability, generality and<br />
performance<br />
60
Selling REST<br />
REST started off as the idealized notion for a<br />
scalable <strong>net</strong>work software application<br />
architectural style<br />
It has become the architectural style of the<br />
Web<br />
Software built around REST principles<br />
demonstrates similar characteristics (NetKernel)<br />
Nothing necessarily to buy, not a steep<br />
learning curve<br />
61
References<br />
Resource<br />
Roy Fielding’s Thesis<br />
RESTWiki<br />
Paul Prescod’s REST<br />
Thoughts<br />
NetKernel<br />
RESTlet<br />
Flickr Hammock Picture<br />
Location<br />
http://tinyurl.com/cvamh<br />
http://tinyurl.com/om38p<br />
http://www.prescod.<strong>net</strong>/rest/<br />
http://www.1060.org<br />
http://www.restlet.org<br />
http://tinyurl.com/ehc7j<br />
62
Change language