Sound advice - blog

I'm working to increase the amount of good information available for REST proponents to point to and use, and for those new to REST to help them understand. There is a lot of half-way information on REST. Much of this information ignores the REST that Fielding describes, and replaces it with one that the author considers workable from their particular persuasion. I'm more of an idealist. I figure that when you are breaking REST tenets, you should at least know how far you are from these tenets.

As such, I have written up a new RESTwiki article as part of my tutorial series: MinimumMethods. This covers the minimal and RESTful use of the classic four REST verbs. I base my analogies around cut-and-paste verbs, rather than CRUD verbs, and I even have ascii art to demonstrate flow of state.

My intention is to round out this series of articles with one solely on RESTful design, but that probably won't happen this weekend

Benjamin

In my continuing effort to communicate what REST is about, I have written my first draft of the restwiki article, WhichContentType. Based on the lessons of my REST Tutorial, this is step number four: Getting content types is the last stage of getting REST right.

It is interesting to view REST through the list of lessons, because it soon becomes apparent that REST is a way of trying to run out of things to disagree on. In protocol development you must agree on a lot before you can exchange useful data. REST says that before you develop any new interface between two pieces of software you should already have:

1. A uniform identifier scheme,
2. A uniform abstraction layer that your software will use to access the interface, and
3. A uniform understanding of a limited set of methods

Combined with a good basic REST protocol such as HTTP, you end up at place where everything but the set of urls and content types can be defined solely on generic technical merits.

The REST approach to content types is that there should be a constrained set of those, too. Every important content type you have should either be a standard, or you should be in the process of developing it into a standard. When enough standard types exist to do 'most everything that you would like to do, your only point of potential disagreement becomes the set of urls your provide. The structure of URLs don't matter, so long as they are stable. That means that we have nothing left to disagree on!

REST pushes all of the social aspects of protocol development into the content-type space, and then challenges you to solve the content-type problem once and for all for your industry or your application type. REST claims that it is easier to come to a social agreement about content types (especially text-based content-types), because they are so easy to extend and ignore extensions on. Consumers just look for what they understand. Producers insert as much information as they think will be understoo. Meeting at that functionality sweet spot in the middle is the social problem you are solving.

Benjamin