REST Goggles

The easiest way to RESTify your thinking is to start by always thinking of paper forms. Assume that your interface to anything and everything is paper forms, and you only interact with anybody else and with services by GETing paper forms, maybe filling them out or just checking/changing them, and then finding on those forms the instructions what to do with them next, mostly in the sense of filing them as an updated version of an existing form somewhere, or by submitting them to a place where new forms are accepted (some place's inbox).

A world completely working like this probably would feel very kafkaesque, because actors in it could be very easily replaced, as long as they're sufficiently trained to do whatever form-based job they're trained to do. They wouldn't even be have to be trained for a specific scenario; if their only job was to accept a form, make sure that the ZIP code on it indeed conforms to an existing U.S. zip code, and then follow the instructions on the form where to file it next. This maybe undesirably almost-perfect reduction of actors to the roles they are playing is what makes this style of design so appealing for large-scale systems where the goal is to dynamically compose functionality from system components, and to make sure that replacing components can be done as easily as possible, without requiring any redesign in the overall architecture or the implementation of other components.

In many real-world settings, components (i.e., people) do more than just slavishly following submit the completed form to window 42 instructions. We will take a more disciplined look at REST and its main architectural principles in the coming weeks, but as a good starting point, this week's assignment asks you to take some scenario involving multiple actors, and analyze it in a way that highlights where it is nicely RESTful, or maybe where it is not RESTful at all. Here are some examples of the thoughts we would like to hear from you:

• If the form says Submit the completed form to window 42, this is helpful only as long as window 42 is well-defined (i.e., the context tells you where that window actually is located, or at least how it can be located). In an ideal scenario, these instructions would be globally unique, so that I could hand the form to anybody anywhere and they would still know what to do next. Or is there some all-knowing service somewhere that is able to tell me how to find window 42? How could that service work?
• What if window 42 is closed? Is there some agreed-on mechanism how there can be a note on it saying Back in 5min, please try window 43? On the Web, these things are called redirects; in the real world, it often is referred to as Business Process Re-Engineering, and one of the biggest challenges is how to make this work without a big bang approach where everybody everywhere has to change everything at the same time, or things will break in really bad ways.
• If window 42 closes and know where people could go instead, can it simply do the direct on its own, or does everybody who so far has pointed to window 42 on their forms now have to update their forms immediately? Can there be a central authority that is approving and publishing the fact that window 42 is closed for the next 5min? What would be the rules for how this authority would have to be consulted by form-filing people?
• What happens if you get a form that was intended for a Klingon speaker and your Klingon is a little rusty? Does everything break, and if so, why? What would it take to make sure that you can easily switch between Klingon and english-speaking worker bees?
• If you put something into the inbox of window 42, how will you ever be able to talk about it? Do you have to return to window 42? Do you even want to return there, or maybe you'd prefer to get a little form containing some identification of what you just submitted and the much more charming person at window 37 could help you just as easily? What would such an identification need to look like that this scheme works reliably?

Your task is to identify and describe a concrete scenario that involves multiple cooperating entities, and where it's likely or as least plausible that some of these actors will change over time. Analogous to the list above, identify at least 5 things in this scenario where you think that things actually work pretty well according to the principles of REST, and where actors could be easily switched out without affecting the overall design. Or choose 5 things where things do not work well (or simply break completely) because too many built-in assumptions. Or mix and match between those categories; but you have to come up with at least 5 things where you explain what works or doesn't work and why it works or doesn't work.

Submit your assignment by 6pm on 2/28 to kimra@ischool.berkeley.edu. (And you might notice here that even a Klingon could use that link, if he would be able to figure out that this is where he is supposed to submit his answer…)