I’m fascinated to see that VIAF merges the human/machine interfaces in two ways:

a machine-centric, but with a human-readably styled version if accessed from a browser

and

a human-centric, get the machine view with a little addition to the URL approach here

the second of which is, in turn, also styled for human consumption if accessed from a browser.

For VIAF see:
http://outgoing.typepad.com/outgoing/2009/08/viaf-and-opensearch.html
http://outgoing.typepad.com/outgoing/2009/12/viaf-and-rdf.html

Http://www.viaf.org
with user interface, sru/opensearch, linked data.

The idea of implementing a predicted future is something that has been recognised by many as an anti-pattern for many years. For example, extreme programming has the never add functionality early.

I’d also like to remind you that open source software development, when managed properly, makes it possible for those needing to expose parts of a core system via an API to do so. In many cases such additions are better made as apart of the core project, something that is also possible in a well run open source project.

This is important because whilst it does not change your proposed model
it allows collaboration across partners to ensure the best, most efficient and most appropriate solution can be built. It means that there is a rapid feedback between upstream and downstream developers. It also means that there is no need for the “donor” project to provide the necessary resources to extend the API or core app with unplanned extensions.

In other words, whilst I agree your alternative pattern is superior (and indeed can be commonly found) we must also consider how we support the ongoing development of the additional API features that new requirements present.

We must either centrally fund this work in response to market demand (central funding) or we must allow the market to make the changes themselves (distributed funding).

Yes – I’m still very interested in REST as an approach in the general ‘resource discovery’ problem space I tend to be focussed on nowadays and I find that the Resource Oriented Architecture (ROA) informs my thinking more and more.

I deliberately didn’t invoke it in this post because I wanted to see if anyone else raised it. Actually, a couple of others have mentioned it in response to this post but on Twitter, rather than as comments here.

It may be that REST’s time still hasn’t quite come as a more mainstream solution, even though we’ve had the wherewithal to implement it for a long time. Then again, I’m beginning to think that the RESTful (i.e. CRUD/HTTP) developments I’ve seen, although of variable quality, probably represent one of those “disappointingly short of the ideal but kinda working nonetheless albeit in a limited way” solutions which tend to win the day….

I note that your final alternative design approach is pretty much exactly the REST approach advocated by Roy Fielding in his thesis. Roy’s fully-REST idea uses hypertext documents not only to transfer state but also to express what actions clients can perform in a given state. Most REST-lite APIs just layer CRUD on top of HTTP without making the state transition graph machine-readably explicit.