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. <2837428374234@foo.org>

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 foo@bar.org -> mailto:foo@bar.org “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

lightbulb@example.org

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?