REST Microscope

Assignment 3 — Principles and Patterns of Organizing Systems Spring 2011

Assigned: Tuesday, March 1st, 2011
Due: Monday, March 7th, 2011 6pm

Introduction:

Starting from the previous assignment, get a little more formal when it comes to defining the essential parts of the scenario. What would the identifiers look like? What would the link interactions look like? What would the representations look like? What kind of state transfers would you need to transfer to make sure interactions are always stateless?

Instructions:

Starting from assignment 2, get a little more formal when it comes to defining the essential parts of the scenario. What would the identifiers look like? What would the link interactions look like? What would the representations look like? What kind of state transfers would you need to transfer to make sure interactions are always stateless? We are not looking for a real formal definition of these things, but for the scenario you have chosen in assignment 2, think through some of these issues. And make sure that you do not limit your imagination by the current Web. Anything can be an identifier as long as it is globally unique. Anything can be an interaction as long as it can be uniformly applied to any of the resources identified within a given identification scheme and its interaction methods.

  • Locations: It is easy to think of locations as identifiers. You can identify them by coordinates, and this is globally unique. What are possible interactions? Probably not so many, you can go there, but that may be it. In many real-world scenarios, identifiers will be essential for uniquely identifying interaction points, so for non-Web scenarios they may be things such as service windows or help counters. Interactions usually mean that clients walk up to these resources, and start interacting by describing a problem they have, or submitting a representation of some workflow artifact, such as a paper form.
  • Paper forms are a really good real-world implementation of RESTful architecture. However, they need to satisfy two main constraints: They need to be self-describing (i.e., just by looking at it somebody has to understand what it is about), and they have to be linked (i.e., just by looking at it, you have to be able to understand where to go next). Imagine the paper forms or artifacts you are using in real life: what would it take to make them RESTful? And what could you do with those RESTful paper artifacts that was not possible before? Go shopping (this is a shopping list for store X) and deliver the goods, maybe?

Be creative in your formalization and most importantly, don't let your thinking be constrained by the Web, HTML, HTTP, URIs, XML, or JSON. There are many valuable lessons to be learned by those implementations of the concepts of identification and interaction and representation, but it is important to first things about the problem space, before jumping to any conclusions regarding the best technology or tool to solve the problem.

Submit your assignment by 6pm on 3/7 to kimra@ischool.berkeley.edu.


Creative Commons License Please send comments to dret@berkeley.edu
Last modification: Monday, 16-May-2011 21:00:18 EDT
valid CSS! valid XHTML 1.0!