AppliedREST

Brian SlettenBosatsu Consulting, Inc.

brian@bosatsu.net

Over 13 years of software development experience

Has own software consulting company for design, mentoring, training and development

Currently working in Semantic Web, AOP, Grid Computing, P2P and security consulting

Speaker Qualifications

2

Why Do We Care?REST ConceptsREST ExamplesREST MotivationBuilding RESTful InterfacesConclusion

Agenda

3

Why DoWe Care?

“Conventional” Web Services are often too difficult for non-trivial tasks (real complexity)

too complex for trivial tasks (artificial complexity)

RPC-based Web Services are mythically interoperable and time/process coupled in painful ways

WS-Dissatisfaction

5

What Makes SOAP Difficult?

Will the real SOAP intended use please stand up?

Remote Procedure Calls

Application Protocols

Tunneling using existing Application Protocols (HTTP)

6

Security Abominations

Tunneling SOAP through firewalls is a questionable practice

HTTP is not a transport protocol!

Intermediaries can only route to endpointsNo actionable semantics in RPC interactions

7

SOA

Service-Oriented Architecture (SOA)An architectural style promoting loose

coupling among software participantsCompanies have rigid definitions of what

constitutes a SOAMust Publish/Find/Bind = UDDI/WSDL/SOAP?

8

SOAP 1.2 and Doc Lit are improvements, but are they necessary?

What is the problem we are trying to solve?We already have an example of a scalable

software architecture for network applications

SOA What?

9

Vendors are fineHowever, too many are trying to sell you the same thing repackaged without thinking about what we are trying to solve

CORBA ORB and tools ✘

EJB Container ✘

SOA-complexity managing tools ✔

Return of the Vendors

10

If You Build It...

...they will use RESTAnecdotally, 85% of Amazon’s users choose REST over SOAP

11

RESTConcepts

What is REST?

REpresentational State Transfer (REST)An architectural style based on certain

constraints designed to elicit properties of scalability and extensibility

An idealized notion of how the early Web should work

Helped drive the way it eventually did work

More than just URLs!

13

Anything that can be named/referred toFiles

Services

Concepts

What is returned can change over timeConsider the “trunk” version of a file in Subversion

Resource

14

Generality by allowing different typesStatic or Dynamic

Flexibility through late binding negotiation of type

Abstract references that do not necessarily need updating when the underlying format changes

GIF->PNG

Resource Abstraction

15

Means of naming a resourceStandard syntax that allows various schemesKnown as URIs (or IRIs)Orthogonal to satisfying the referenceOne of the main missing pieces of “normal”

web services

Resource Identifier

16

A particular deferencing of a Resource Identifier to a Resource at a particular time

Think the file “index.html” or

“Today’s Slashdot Page”

A byte-stream tagged with metadataCould change based on request or

processing/display capabilities of clientFirefox vs. WAP

Representation

17

Accompanies a RepresentationAllows intermediaries to make decisions (caching)

Helps clients know how to display the Resource

IncludesMIME Type

Last modified date

Resource/Representation Metadata

18

REST Verbs

Design decision to minimize the breadth of the interface

RPC is completely open-ended from an action perspective

19

GET

Retrieve a Resource

20

POST

Create a Resource

21

PUT

Update a Resource

22

DELETE

Remove a Resource

23

RESTExamples

All of these web servers can certainly expose RESTful interfaces

Once you look under the hood, however, it becomes more complicated

Why Not Apache? Tomcat? IIS? Jetty?

25

NetKernel

Ground up generalized architecture built around REST

Microkernel maps requests for resources into the software components that will satisfy the requests

Benefits from the architectural properties we have discussed

26

RESTlet

Lightweight Java-based REST frameworkAlternative API to Servlets for cleaner match

to REST conceptsSupport for filters, authentication logging,

blocking and non-blocking IO

27

RESTMotivation

Concepts are based on Roy Fielding’s work- On his Ph.D. Thesis “Architectural Styles and the Design of Network-based Software Architectures”

- On HTTP 1.0/1.1 Standards

- On Apache, libwww and related projects

The REST is History

29

Software Architecture

30

“A software architecture is defined by a configuration of architectural elements —

components, connectors, and data —constrained in their relationships in order to

achieve a desired set of architectural properties.”

-- R.F. Thesis

Architectural Style

31

“An architectural style is a coordinated set of architectural constraints that restricts the

roles/features of architectural elements and the allowed relationships among those elements within any architecture that

conforms to that style.”

-- R.F. Thesis

Architectural Effects

Choice of a particular architectural style has consequences for how components communicate

Affects overall growth potential and performance of a system

32

Architectural Properties Of Interest

PerformanceScalabilityGeneralitySimplicityModifiability

33

REST Goals

Provide architectural guidanceMinimize latency of network software

applicationsMaximize component independence and

scalabilitySupport extensibility through small, well-

defined abstract interfaces

34

Supports Separation of Concerns (SOC)UI code can be localized in clientBackend logic can be localized in server

(reused by different clients)

Client-Server

35

Client-Server

36

All parameters travel with requestNo session information maintained on serverImproves scalability through load-balancingImproves visibility of intermediary processors

Stateless

37

Stateless Client-Server

38

Decentralization of dataCan be wholly or partially copied aroundImproves accessibility and scalabilityImproves user perception of performanceIntroduces need to keep data in synch

Replication

39

Form of replication when external data set is too large to copy locally

Results of individual requests can be captured and re-served later

Cache

40

Improves generality, simplicity and reusabilityCan cause performance issues when data

needs conversion to/from standard formats but REST tries to optimize for average Web data types

Uniform Interface

41

Stateless Client-Server w/ Cache and Uniform Interface

42

Managed dependencies between layersImproved modifiability by compartmentalizing

visibility to neighboring layers

Layered System

43

Layered Stateless Client-Server w/ Cache and Uniform Interface

44

REST Properties

45

Based on figure from R.F.’s thesis

BuildingRESTful

Interfaces

What is Controversial

47

URI OpacityHow much meaning should there be in

URIs?How do naming schemes

affect intermediary processing?make the Web brittle?differ by language context?

tbl on URI Opacity

48

“When you are not dereferencing you should not look at the

contents of the URI string to gain other information.”

http://www.w3.org/DesignIssues/Axioms.html

http://www.flickr.com/photos/ajstarks/152558066/

Roy on URI Opacity

49

"REST does not require that a URI be opaque. The only place where the word opaque occurs in my dissertation is where I complain about the opaqueness of cookies. In fact, RESTful applications are, at all times, encouraged to use human-meaningful, hierarchical identifiers in order to maximize the serendipitous use of the information beyond what is anticipated by the original application."

http://tech.groups.yahoo.com/group/rest-discuss/message/3232

UnREST

50

REST is largely defined by a small number of semi-formal specifications, a larger number of secondary publications and writings, and the collected design notes, anecdotes, and essays of Tim Berners-Lee. Among these artifacts there are a number of contradictions, a number of ambiguities, and perhaps at least some assertions and principles which are not sufficiently supported. Where certain

principles and assertions can be formalized and their observable impact quantifiably understood, REST is solid...

My beef with the Opacity Axiom (hereafter, "the axiom") is that it (needlessly, IMHO) discards the important and useful concept of structured naming and semantically rich namespaces. In filesystems research and elsewhere over the last decade or two (described in slightly more detail in OpacityReconsidered) many researchers

have recognized the power and utility gained by enriching the structure and semantics of names and namespaces. The Web, curiously, runs absolutely counter

to this trend.

--Jeff Bone

(http://rest.blueoxen.net/cgi-bin/wiki.pl?OpacityMythsDebunked)

Encoding Meaning in Structure

Which is more meaningful? (To Whom?)http://www.bosatsu.net/talks/NFJS/2006/REST

http://www.bosatsu.net/12123125231234123412

51

Hierarchies

52

http://www.bosatsu.net/talks/NFJS/2006/REST

Organizational

TemporalTopical ?

Hierarchical + Non-Hierchical

53

http://www.bosatsu.net/talks/NFJS/2006/REST/Reston

Organizational

TemporalTopical ?

When You Aren’t Sure

54

http://www.bosatsu.net/talks/NFJS/2006?talk=REST&location=Reston

Use query strings for non hierarchically-related attributes

Pragmatic REST

At a minimum, URIs must be able to be treated opaquely

Hierarchical spaces are conveniently represented through the path portion of a URI

Non-hierarchical attributes should be delegated to the query parameters

55

Do not rely on sessions or other state at the application level

Use nouns, not verbsDon’t abuse GET!No side effects

Don’t abuse POST!Limit use to creation, not conversational GET

What Isn’t Controversial

56

Real World Examples

57

Amazon http://www.amazon.com/gp/aws/landing.html

eBay http://developer.ebay.com/developercenter/rest

Yahoo! http://developer.yahoo.com

Bloglines http://bloglines.com/services/

Atom http://tools.ietf.org/wg/atompub/draft-ietf-atompub-protocol/

Ruby on Rails (1.2)

http://www.rubyonrails.org/

Conclusion

Describing RESTful services to clientsPublishing metadata about RESTful servicesTransactionsConversational State

Open Issues

59

REST may not be the only answer, but it is often the more straightforward answer

REST is more than using URLs to access web services

It is the deliberate application of architectural constraints to elicit the properties of scalability, simplicity, modifiability, generality and performance

Main Points

60

REST started off as the idealized notion for a scalable network software application architectural style

It has become the architectural style of the Web

Software built around REST principles demonstrates similar characteristics (NetKernel)

Nothing necessarily to buy, not a steep learning curve

Selling REST

61

References

62

Resource Location

Roy Fielding’s Thesis http://tinyurl.com/cvamh

RESTWiki http://tinyurl.com/om38p

Paul Prescod’s REST Thoughts http://www.prescod.net/rest/

NetKernel http://www.1060.org

RESTlet http://www.restlet.org

Flickr Hammock Picture http://tinyurl.com/ehc7j