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
|