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
service!)...
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).
Regards,
Till
--
http://twitter.com/tillk
