In message
<[log in to unmask]>, Mia Ridge
<[log in to unmask]> writes
>I thought this article might provide some useful background for those who
>are thinking about implementing APIs, and it's possibly helpful for those
>who still aren't sure exactly what an API is or what it does.
I'd like to pick up on this point, Mia, as I think I fall into your
latter category.
I always thought that an API was an Application Programming Interface,
and that it provided programming functionality which you can call up
through a well-defined set of procedure/function calls. Looking at the
Programmable Web directory, I see things which fit this general concept:
"IBAN and SWIFT validation services", "RDF proxy service", "Bug and
issue tracking", etc.
When I set up an interface which gives access to museum data in response
to external HTTP requests, I don't think that I am providing
"programming functionality" to the outside world, just data. Cool
museological Linked Data RDF data, perhaps, but data nonetheless. So,
in my view, that's not an API.
Or have I got the wrong end of the stick?
Richard
--
Richard Light
XML/XSLT and Museum Information Consultancy
[log in to unmask]
**************************************************
For mcg information and to manage your subscription to the list, visit the website at http://www.museumscomputergroup.org.uk
**************************************************
|