REST Compared
Mark Baker, Idokorro Mobile Inc.
REST Compared
Will compare with other “Distributed Object”-like architectural styles i.e. “chuck messages at things with
behaviour, state, identity”
OO RPC (e.g. CORBA, DCOM, RMI)
Internet Email
Tuple Spaces
REST Compared
Comparison criteria Object identification
Qualities of identification system Binding style
Given an identifier, the point at which an agent knows the interface
Application state engine How an application makes progress
Focus on “uniform interface” “The central feature that distinguishes the REST
architectural style from other network based styles is its emphasis on a uniform interface between components” – Roy Fielding, in his dissertation
Object Identification; OO-RPC
In practice, uses OIDs/UUIDs
Identifier only means something within context of system
Object Identification; Internet Email
Email addresses for mailboxes In practice, recognizable in all contexts
RFC 822 Message-Ids for messagese.g. <[email protected]>
Object Identification; Tuple Spaces
Typically uses local identifiers scoped to some host/port
Tuples are not identified
Object Identification; REST
URI Scheme as key innovation Provides hook for late binding Makes explicit what is implicit with other identifiers
“U” for Uniform/Universal Enables other systems to be engulfed
ftp host/path -> ftp://host/path [email protected] -> mailto:[email protected] “Principle of Independent Invention”
Resources and Representations identified by URI
Binding Style;OO RPC
To service offered by object;Early (aka static) binding I.e. Identifier is insufficient information for
use
To “management” interface;Late (aka dynamic) bindinge.g. IUnknown/IDispatch, CORBA::Object
Binding Style;Email
Late binding for mailboxesVia SMTP DATA methodSee an email address, invoke DATA
Binding Style;Tuple Spaces
Late bindingSee a Space, invoke in/rd/out,
read/write/take, etc..
Binding Style;REST
Late bindingSee a URI, invoke GET/PUT/POST/etc..
App State Engine;OO RPC
Invoke methods Invoice.getSupplier()Sometimes get back an OID
Sometimes mobile code (load(“foo”)).execute()
App State Engine;Email
Partly hypermedia “Reply to” a hypermedia action
Mostly ad-hoc
App State Engine;Tuple Space
Blackboard styleTemplate matching on read()
Optional async notification of matches
Tuples don’t identify spaces
App State Engine;REST
HypermediaWalk a typed graph
e.g. <a rel=“supplier” href=“http://example.org/supplier”>Supplier</a>
Each step declares possible state changes as hypermedia links
Lightbulbs with OO RPC
Interface Lightbulb
{
void turnOn();
void turnOff()
boolean isOn();
}
Many interfaces possible
Lightbulbs with Email
No reliable view of state of bulb; Inherent restriction with single, non-
idempotent mutator like SMTP DATASimilar issue with Tuple Spaces …
Lightbulbs withTuple Spaces
Interface Lightbulb
{
void write( Tuple );
Tuple read( Template );
Tuple take( Template );
Handle notify( Template );
}
Lightbulbs withTuple Spaces
Many Bulb-to-Space mappings; Bulb state = sum(tuples) mod 2 Bulb state = num(tuples) mod 2 Bulb state = last tuple
Choice determines many qualities of resulting system Can a client reliably determine the state? How easily can we recover from partial failure?
This issue is common to OO RPC and Email
Lightbulbs withREST
Interface Lightbulb
{
Representation GET();
void PUT( Representation );
void POST( Representation );
void DELETE();
}
Lightbulbs withREST
GET() returns “on”, “off”PUT( “on” ) turns on, PUT( “off” ) turns offOnly one Bulb-to-Resource mappingPartial failure, view of system state more
manageable
Related bulbs, or other things, can be discovered as hyperlinks via GET
PossibleDiscussion Points
What about a uniform interface makes it unsuitable for machine processing (as some have suggested)?What do we need to enable this?
Other Internet-scale architectural styles exist today, and will continue to do soWill Web Services be one?