REST, Self-description, and XML

For XUGO

Mark Baker

January 15, 2004

Overview

Introduction to REST
Self-description
Self-description and XML
A surprise
Conclusion

REST

"REpresentational State Transfer"
A software architectural style

a coordinated set of architectural constraints

Approximates "best of the Web"

as viewed by Roy Fielding, principle author of HTTP 1.1, URIs

Name intended to evoke image of "document exchange"

Key REST constraints

Self-descriptive messages
Stateless interaction
Resource identification
Uniform interface
Hypermedia as engine of application state

Self-descriptive messages

We'll get to this ...

Stateless interaction

All the data needed to understand the message, is in the message
Very important for security, scalability
Cookies break this constraint

Resource identification

Name things with URIs
Don't name multiple things with the same URI

Uniform interface

All remote methods that are used are meaningful to all resources
For example;

GET; give me a representation of the state of the resource
PUT; set the state of the resource to this
POST; process this
DELETE; remove all representations

Note; nothing specific to books, stock quotes, weather reports, ...

Hypermedia

Clients move from state to state via URIs
Stateful interactions break this, e.g. cookie auth

as does "URI sniffing"

Self-describing

The meaning of a message is fully grounded in public specification, or the Web itself
See also ...

"Follow your nose" -- Dan Connolly
"Specs count", a keynote at WWW2002 by Tim Berners-Lee

Self-describing

RESTful HTTP messages are self-describing, due to;

Statelessness; all data you need to lookup, you've got
Standard uniform interface semantics; look up meaning in HTTP 1.1 spec
Standard media types; lookup in IANA registry (soon to be looked up on Web)
Explicit cacheability; indicated by cache headers and/or implicit in method - both per HTTP spec

"Follow your nose"

Lookup the meaning of bits in a message, "outside in"
An example, stolen directly from the aforementioned Timbl talk ...

You have an ethernet cable

... which only takes Ethernet packets.

Ethernet packets have a field

.... which takes a value

... which indicates that the packet conforms to the

Internet protocol

You send an Internet packet

... which has a field which indicates the protocol.

A particular value indicates that that the rest of the packet conforms to...

the Transmission Control Protocol specification

The TCP spec

specifies that a particular field in a a packet is a port number. The significance of this is defined by the

IANA Port Number Registry

lets you know that a value of 80 indicate that the TCP byte stream conforms to the

HTTP Protocol Specification

The Hypertext Transfer Protocol (HTTP) specification

specifies that when a response has a code of 200 then the interpretation of the rest of the response is determined by a

MIME type.

The MIME type

is registered in a list with IANA, which specifies that, for example, if the MIME type is application/xml, then the relevant specifications are the

XML and Namespaces specifications

Hold up!

I disagree with Timbl here; you cannot "follow your nose" from application/xml in RFC 3023 to document-specific processing (i.e. no namespace dispatching)

RFC 3023 says;

An XML document labeled as text/xml or application/xml might contain namespace declarations [...] Such a document might be handled by applications that would use this information to dispatch the document for appropriate processing.

"Might". Not "Will"

XML; what's the X stand for again?

Can I extend any XML document?

Not without the schema!
You might be breaking an application somewhere

How can we fix that?

One way is to include schema

By reference is stateful
By value is bloatful

Ok, but extensions are entirely opaque to application; we can do better
"Partial understanding" of extensions would be useful

Can we do that?

Yes!

Assign meaning to element hierarchy and attribute extension
So <foo> child of <bar> means such-and-such a relationship exists between foo and bar

  <Person xmlns="http://example.org/foofoo/">
    <name>Mark Smith</name>
    <age>55</age>
  </Person>

Relationship between "Person" and "name"/"age" is one of resource/property
Tie it all together with a new media type so we can follow our noses

Cool! What can we call it?

RDF!

the W3C's Resource Description Framework

Comparing RDF/XML & XML

  <Person xmlns="http://example.org/foofoo/">
    <name>Mark Smith</name>
    <age>55</age>
  </Person>

XML+Namespaces specs only tells you the namespace and the structure
RDF spec tells you

there's a "Person" with "name" of ...
the URIs for all terms
terms may be opaque to app, but can be looked-up via GET!
that you can add new properties (and other stuff) without breaking any apps

More RDF

  <a:Person xmlns:a="http://example.org/foofoo/"
     a:name="Mark Smith" a:age="55"/>

Semantically identical to previous example

Can also do; collections, provide URI for "Mark Smith", ...

Conclusion

Self-description is HARD ... but IMPORTANT

RDF/XML "extends" XML with self-descriptive processing and extensibility model