November 20, 2002

Interface Uniformity and Application Protocols

Greg Reinacker posted some interesting comments in his weblog about Interface Uniformity:

You can retrieve anything the same way, but you can't process it without knowing more specifically what it is. And while it's nice to have an interface that is essentially type-less [...], it's not as nice if the returned types can't be coerced into something you can use.

This is the point that has bothered me about the whole REST concept right from the start of all the "REST is Best" debates. HTTP GET does not provide a true application-to-application protocol because it is always dealing with generics.

Once you get the contents of the resource you just retrieved with a HTTP GET request, what do you do with it? In the normal case of a web page, the contents are given to a browser program to render the contents as HTML, or a JPEG image, or whatever the appropriate rules defined for rendering that specific content type. The "application protocol" in this case really lies with the browser and HTML rather than the underlying HTTP level interaction. Without this "application level" processing provided by the browser, the interaction just boils down to a blind transfer of a (binary) payload, and the data is not in and of itself inherently processable.

This has an interesting comparison with web service descriptions which I will cover in a separate post.

Entry categories: Architecture Web Services
Posted by Jorgen Thelin at November 20, 2002 12:30 PM - [PermaLink]
HTTP is an "application of generics", in fact. That's a good way of putting it. If all you know is that something has identity, state, and behaviour, what could you do to it? Serialize the state, with GET. Replace the state with PUT. Submit some other state for processing by the "behaviour" of the thing with POST. Reserve a lock on state changes with LOCK. Ask to be notified if the state changes with MONITOR. etc.. But what do you do with the response of a GET? Well, you process it. For a browser that means "render" to the user, or "save as file", but "process" could be anything. What kind of things could a stock quote analysis app do with a stock quote? It's open-ended. Posted by: Mark Baker on November 21, 2002 07:29 PM