REST, Self-description, and XML
January 15, 2004
- Introduction to REST
- Self-description and XML
- A surprise
- "REpresentational State Transfer"
- A software architectural style
- a coordinated set of architectural constraints
- Approximates "best of the Web"
- 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
- All the data needed to understand the message, is in the message
- Very important for security, scalability
- Cookies break this constraint
- Name things with URIs
- Don't name multiple things with the same URI
- 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, ...
- Clients move from state to state via URIs
- Stateful interactions break this, e.g. cookie auth
- The meaning of a message is fully grounded in public specification, or the Web itself
- See also ...
- 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
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
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
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
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
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
"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?
- Assign meaning to element hierarchy and attribute extension
- So <foo> child of <bar> means such-and-such a
relationship exists between foo and bar
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?
the W3C's Resource Description Framework
Comparing RDF/XML & XML
- 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
a:name="Mark Smith" a:age="55"/>
Semantically identical to previous example
Can also do; collections, provide URI for "Mark Smith", ...
Self-description is HARD ... but IMPORTANT
RDF/XML "extends" XML with self-descriptive processing and extensibility model