An "historic" look at specific vs. generic interfaces

I stumbled upon an “old” paper by Dan Larner yesterday that I first read when it was published back in ’98, but had forgotten all about. I find it poignant today not because I agree with its conclusions (I don’t), but because it so well describes the tension between specific and generic interfaces, albeit without actually acknowledging the tension 8-O

I liked this image in particular;

At the top you see the generic objects/interfaces, while at the bottom are the specific interfaces; Printer, Scanner, Copier (this is Xerox, after all). But why do those services require specific interfaces? Check out the methods on Printer; Print, CancelJob, Status. Why is that needed? Why can you just not call GET on the printer to retrieve it’s status, POST to the printer to print a document, and DELETE on a job resource (which is subordinate to the printer) to cancel a job? Simple.

Many of the folks behind HTTP-NG were from PARC where ILU, a CORBA ORB with some funky extensions, provided the impetus for their W3C contributions. Like Web services proponents, their backgrounds were with systems which didn’t constrain interfaces, and so it was pretty much an implicit requirement that HTTP-NG would need to support specific interfaces by basically being a messaging layer ala SOAP. It’s too bad they didn’t take the time to study what was capable with the HTTP interface specifically, or even constrained interfaces in general. I think that’s a big part of the reason why HTTP-NG flopped.

Leave a Reply

Your email address will not be published. Required fields are marked *