I'm preparing for an internal REST presentation. I'm going to use this blog as my presentation platform. Power Points can be pretty, but I think that it's ideal to have a presentation about REST in an HTML/HTTP/URL environment.
Here's a rough outline of the presentation:
- A brief history of the web, from a data-oriented perspective
- REST by Roy (gbiv.com)
- Java RESTful Services - JAX-RS
A brief history of the web, from a data-oriented perspective
W3C standards: URI, HTTP, HTML - the foundations of the web. The first spec for these three protocols proposed in 1994.
- URI - Anything important (a Resource) has an identifier.
- HTTP - Use a standard communication protocol. GET/POST verbs, URLs, headers (including caching)
- HTML - A standard UI Resource language, but also a language that expresses relationships with other Resources (a, src, form...).
There has been a progression of the way people and computers interact on the Web on top of those W3C standards.
- The Web - Where were you the last decade and a half? - data interactions using HTML links, images, forms
- Web 2.0 - AJAX as an optimization. Data oriented communication (AJAX) to provide desktop-like functionality, plus a whole bunch of other goodies outlined by Tim O'Rielly and of course the rounded edges . Mashups and serendipity.
- Web 3.0 - (huh? is this for real?) The Semantic Web, hyper-connected data - connected computers; and uber-social media - connecting hyper people. Engineered Serendipity.
REST by Roy (gbiv.com)
So what does this have to do with REST? REST stands for Representational State Transfer. REST is the architectural principles behind the distributed programming principles of the web.
Roy Fielding co-wrote the original HTML/HTTP/URL W3C specs and still heavily involved with those standards to fill in some details that came up with the relatively new addition of data-oriented services (Don't use OPTION, it doesn't support Caching; the behavior of PUT with complex caching). He wrote the book (or rather the dissertation) on REST. He's the co-wrote Apache httpd and has since been on the Apache Software Chair commitee. He's been involved with Apache Sling which is a product centered around JCR.
REST comes down to the following principles (quoted from Chapter 5: Deriving REST):
Client Server - the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.
Stateless Communication - each request from client to server must contain all of the information necessary to understand the request. Any instance of "the server" should be able to process an incoming request.
Cache - Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable
Uniform Interface - REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state
Layered System - By restricting knowledge of the system to a single layer, we place a bound on the overall system complexity and promote substrate independence
Code-On-Demand - REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts
If you want, you can read more about it in a previous blog entry of mine - "What's REST Anyway".
A quick word about Statelessness: This constraint is a bit murky. It's not that the server can't store "resource state". This constraint is broken when the client is tied to a specific instance of the server (similar to what happens with jsessionid)
A quick word about Uniform Interface:
identification of resources - URLs, URNs - something globally unique and well understood
manipulation of resources through representations - HTML, form fields, JSon, XML, PDF... You're not manipulating the resource itself. Content Negotiation
self-descriptive messages - A person or a computer should be able to read the represtation. HTTP headers describe quite a bit about requests and responses, standardized verbs (GET/POST/PUT/DELETE/OPTIONS/HEAD). HTML forms are sort of like WSDL - defining future communication.
hypermedia as the engine of application state (HATEOAS) - the most controversial and least understood REST constraint. I wrote about it, in fact my blog is full of it. BTW, some people pronounce this constraint Hate Yo' A$$.
On October 2008 Roy Fielding got really frustrated that so-called REST APIs don't implement this constraint and he explained the HATEOAS constraint (now renamed "The hypertext constraint") further. I read Roy's post quite a few times, but still didn't fully GET it. (quick word on single point of entry, workspaces and Serendipity)... I asked the experts on the rest-discuss Yahoo group about how and why they implement the hypertext constraint and got some astounding answers.
Q & A on REST - (if we have time)
- Roy Fielding's REST Thesis - Architectural Styles and the Design of Network-based Software Architectures(December 2000)
- Bill Burke's Introduction to REST (August 2008 - DZone)
- How to GET a cup of coffee (October 2008 - InfoQ)
- Roy Fielding REST APIs Must Be Hypertext Driven
Java RESTful Services - JAX-RS and RESTEasy
JAX-RS (JSR 311) - Java API for XML and RESTful Services. It's a standard created by the java community's REST experts. It's a collection of annotations, interfaces and some guidelines on how to map data-oriented services.
- Bill Burke's Putting Java to REST (September 2008 - DZone)
- An overview of JAX-RS 1.0 Features
- James Strachan's JAX-RS as the one Java web framework to rule them all? (January 2009 - blog)
A quick Web + JAX-RS demo. with XML/JSon/HTML/Form representations (and a dash of Spring and Jetty). Let's see @Path and other JAX-RS annotations. JUnit Test with Embedded Web Server
Possibly another demo - Flickr client and RESTEasy client goodies - embedded Web Browser with MozSwing, with Resteasy's built in client-side cache.
What do you think you could do with an embedded server and an embedded browser?
Q & A?