app-specific contracts: win? lose? [was: section 1, intro, for review]

On Fri, 2002-03-22 at 16:13, Roy T. Fielding wrote:
> Don Box:
> > However, this ignores the fact that the community at large wants to
> > build application-specific contracts.
> I don't believe the "community at large" wants anything even remotely like
> application-specific contracts.

I have found this to be a fascinating tension for quite some time.

I wrote an essay about it for a magazine back in '97...
an excerpt:

What are the odds that the client and the server share any richer
interface than HTTP and forms? For parties with a manually established
relationship, the odds are quite high. But such situations don't call
for any new infrastructure -- just creative applications design. In
order for dynamic interface discovery and negotiation to be useful, we
need to see a marketplace of interfaces, from commonly used interfaces
and frameworks to highly specialized but widely known interfaces.

The fascinating question that comes to mind is: does this commerce in
rich interface have an overall positive or negative impact on the
robustness of the system? As the richness of an interface increases, so
does its complexity, and down go the odds that the two parties have
implemented the subtleties in a compatible way.
-- editorial of the Mar/Apr 1997 issue of Web Apps Magazine

In that article, I leaned toward saying: yes, it's worth
deploying interfaces richer than GET/PUT/POST/DELETE.

Then, of course, I changed my mind...
> I think we got some things right. I think GET/PUT/POST
> is enough. Perhaps having a principled way of specialize
> POST (say... a header field that carries a URI ala
> HTTP ext) should have been there from the beginning. 

  -- Dan Connolly <>
  Date: Tue, 15 Aug 2000 01:15:50 -0500
  Subject: HTTP goofs and musings 

	forwarded to fork

Dan Connolly, W3C

Received on Monday, 25 March 2002 18:17:23 UTC