The Path to HTTP/REST Mastery

2009-12-22 @ 17:51#

want to be known as an HTTP/REST guru? ready to step onto the path of HTTP/REST mastery? here's my list of things you should have already done, be doing now, or be preparing to do in the near future. if you've got this list taken care of (not just 'covered', but really nailed) then i'd consider you eligible for the title of HTTP/REST Master.

The Qualifying Round

Build an HTTP-compliant server application
  1. Support conditional gets/puts
  2. Include caching support (for external agents)
  3. Support standard authentication (Basic/Digest)
  4. Support conneg (including media-type, compression)
  5. Extra points for successful support for language conneg
Build an HTTP-compliant client application
  1. Honor conditionals (304)
  2. Support basic auth (401,403)
  3. Honor private caching (minimal)
  4. Support conneg
  5. Extra points for illustrating proper support for 405, 406, 415, 416, 417
  6. Bonus for proper support for 503 (including retry)

The Main Event

Build a REST-ful HTTP server app
  1. Minimal pre-published links (i.e. 1)
  2. Rely heavily on media-type and rel values
  3. Flow controlled only by links
  4. Extra points if you support more than one media-type
  5. Bonus for REST-ful handling of batch-type operations and long-running tasks (explain your answer)
Build a REST-ful HTTP client app
  1. See all of the above
  2. Extra points for building the client without using a Web browser
  3. Bonus awarded for building a client using a non-scripted Web browser
Build an HTTP server/client machine-to-machine REST-ful implementation
  1. Same as the first two above, but build a "goal-seeking" client
  2. Extra points if you can change the server implementation w/o breaking the client
  3. Bonus awarded if you create additional clients that seek other goals w/ the same server implementation/media type
Document a REST-ful server app
  1. Everything the dev needs to write a client
  2. Focus on documenting the media-type and the link relation values
  3. Minimal pre-pub links (1) (e.g. _not_ an URI/API list as documentation)
  4. Extra points if you make all documentation available online via OPTION extensions
  5. Bonus if you can write a bot that trolls the server to collect up all the available documentation at design time
Version an existing REST-ful app
  1. Handle soft scheme/semantics versioning (ignorable)
  2. Handle hard scheme/semantics versioning (new resources/flow needed)
  3. Extra points for including link management including 3xx and, if needed, 410 redirects for old URIs
  4. Bonus points if you can illustrate asynchronous version-compatibility (v2 client can work w/ v1 server, v1 client can work w/ v2 server)

The Finals Round

Define new Link relation values for an existing media-type
  1. Use in server and client app
  2. Extra points if you document them correctly (see main events)
  3. Bonus if you can implement new functionality w/ existing IANA-document relation values
Design and implement a new media type
  1. Scheme for the data (format)
  2. Semantics (embed and nav links + important data elements)
  3. Document any new link relations
  4. Use in server and client app
  5. Must include proper documentation (see main events)
  6. Extra points for preparing IANA registration documents for any new link relations
  7. Bonus awarded for preparing an RFC draft for the new media-type
Design and implement new REST-ful protocol (not HTTP)
  1. Use all the _required_ constraints (code-on-demand not required)
  2. Build server/client apps that use this new protocol
  3. Extra points for creating more than one sample server/client application w/ the new protocol