Andrew Hankinson schrieb:

> I think that it's supposed to be the exact opposite. APIs, and 
> especially web APIs, exist to provide access to your data outside of a 
> specific vendor implementation. 

If they are open, well documented, free of non disclosure agreements, 
free to be used/implemented in any kind of software and scenario (I 
don't claim they need to be free of fees if they provide a valuable 
I heard, there are APIs that don't work that way... Those may lock you 
in, yes.

> That way you can have your OPAC from 
> $BIG_VENDOR, but use the bibliographic data from it in 
> $OPEN_SOURCE_PROJECT without having to access the database directly 
> (causing your DBAs to have sleepless nights.) Theoretically anything 
> that comes over HTTP is some form of structured text, so there shouldn't 
> be unreadable binary blobs.

Oh no, please. We are doing some things that way: Screenscraping HTML. 
Sleepless nights...
That's as good as a publisher sending some hundred thousand metadata 
records in a somehow "structured" Word document (no joke, Word even 
refused to open that file, OpenOffice did, very nice: Journal Titles 
etc. in the headline, article data on the page, must have been a real 
punishment for the one compiling that beast).

> In theory, that's how it's supposed to work. There's still crappy 
> implementations, but that's not the fault of the API

I think you mix up APIs with open standards or documentation...
APIs are everywhere in software (they are a fundamental concept of 
software design), but most are not "open" or intended for "public use" 
(even Microsoft has a long tradition of APIs, but it took them a long 
time to embrace the power of open APIs in their products).