A blog entry by Paul Walk – An infrastructure service anti-pattern – drew some attention a while ago. He argues against a model in which a service provider independently develops APIs and a user interface, and in which, accordingly, the APIs are developed in advance of actual use or explicit external requirements. He claims that this model underlies aspects of historic UK higher education thinking, where application to application interoperability was seen as a good in itself and was often built into initiatives from the start in mistaken anticipation of hypothetical future use.
His alternative suggestion is that an API should be developed in tandem with real requirements generated by the user-facing application supporting user interfaces. This motivates the API with real requirements and strengthens the chances of being able to support third party application developers who want to write to the API. He suggests a refinement of this approach as follows:
An interesting alternative to this is the approach of combining the user-facing web pages and the machine-actionable API into one interface, through embedded RDFa for example:
It remains to be seen how this approach is going to work out over time, but we have seen hints of simpler approaches to combining user and machine interfaces in the past, such as RSS being styled to give a decent human-readable interface, or earlier attempts to do interesting things with XHTML. [An infrastructure service anti-pattern]
I left a note suggesting that VIAF and Worldcat Identities were architected along the lines of this last picture. For VIAF details, for example, see Thom’s posts here and here. Several interfaces – OpenSearch, linked data, user-oriented – are supported by an underlying SRU interface. Here is Paul’s response, noted here with his permission:
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.
