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.
|
