Hi Jeremy
I'd go lightweight every step of the way. So XML rather than JSON (and yes, I know that strictly speaking JSON is "lighter" in terms of KBs, but less widely supported). Ditto, REST rather than SOAP. RSS is also good (it has the word "simple" in it) :-)
In terms of SLA, Joe and others are aware that you can build fairly comprehensive caching and error mechanisms into these various systems which solves some of the questions. I also like the "email me if it changes" idea. I'm fairly interested in the community voting aspect to this - it could be one to look into. http://www.programmableweb.com/apis for instance has a simple framework for public APIs which lets you vote - but not necessarily on uptime or reliability.
My previous email still seems to have been captured and held by the MCG mail filter and I won't bother re-sending it now, but just to say that I'm currently at some training with Google and implemented (in not much time) an Ingenious (www.ingenious.org.uk) search via the Google Enterprise "OneBox" approach (http://www.google.com/enterprise/gsa/onebox.html), and all because of a lightweight "display page as XML" approach we took when building the Ingenious site.
The lesson is, simply: create XML renderings of your content if you can't build a full featured API. It'll be maybe an extra day of developer time, but the benefits are long-standing and very tangible...
Cheers
Mike
Mike Ellis
Solutions Architect
Eduserv
________________________________
[log in to unmask]
tel: 01225 474300
fax: 01225 474301
www.eduserv.org.uk
________________________________
________________________________
From: Museums Computer Group on behalf of Ottevanger, Jeremy
Sent: Wed 13/02/2008 15:13
To: [log in to unmask]
Subject: Re: API use-cases
Many thanks, Joe, that's brilliant. These requirements are, as you say,
every bit as important as the functionality that is available. Copyright
and the reliability of the service especially will be both potentially
thorny problems, and utterly vital. An SLA may be unlikely, however
given that content providers will be one target audience and can
justifiably demand a decent level of service in return for their
content, some form of agreement may be appropriate.
Do you have any preferred means of access, by the way? Any technology
you particularly favour? Would you want, say, a JSON interface, or are
you happy with RSS returned (to browser or server) in response to a
query? Or something else - some specific metadata format for object
data, say?
Many thanks again for your thoughts
Cheers, Jeremy
Jeremy Ottevanger
Web Developer, Museum Systems Team
Museum of London Group
46 Eagle Wharf Road
London. N1 7ED
Tel: 020 7410 2207
Fax: 020 7600 1058
Email: [log in to unmask]
www.museumoflondon.org.uk
Museum of London is changing; our lower galleries will be closed while they undergo a major new development. Visit www.museumoflondon.org.uk to find out more.
London's Burning - explore how the Great Fire of London shaped the city we see today www.museumoflondon.org.uk/londonsburning
-----Original Message-----
From: Museums Computer Group [mailto:[log in to unmask]] On Behalf Of
Joe Cutting
Sent: 13 February 2008 14:35
To: [log in to unmask]
Subject: Re: [MCG] API use-cases
>>
OK, at the risk of boring you all with this subject, but in the hope of
squeezing out a little more feedback on what should and shouldn't be in
an API for the EDL...
>>
Ok, my major use case for this type of thing is for exhibition displays
and interactives.
Typically I download the data from an external source and re-display it
on a screen in the gallery - sometimes adding new ways of interacting
with it.
Here's an example which downloads news headlines from the BBC and turns
them into a "Have I got news for you" style missing words quiz.
http://www.joecutting.com/newsquiz.asp
The original exhibit is displayed on a 55 inch LCD screen in a science
centre and is operated by large pushbuttons.
Issues that you get for this kind of use:
- Ideally you need to have access to all the data and high resolution
versions of the images. For the exhibit above we wanted to show the
whole story but the BBC doesn't make that data available - there's an
RSS feed with a link to a relevant page but that's no good unless you're
using a browser. Having said that any information you can provide is
better than nothing.
- Copyright. You need to decide the copyright situation for data reuse
in advance - not on a case by case basis.
The web version of the news quiz doesn't have pictures because the BBC
doesn't have full copyright clearance on the images it uses
- Data integrity. The BBC feed is designed for being displayed in web
browsers and sometimes the XML isn't valid. Browsers can cope with this
but external applications can't.
- Service level. If someone else is using your feed then they need to
have some level of confidence in it - this is particularly important in
a exhibition setting. I'm not a big fan of service level agreements -
particularly if no money is changing hands which makes them difficult to
enforce. Instead I would recommend that
a) Users can register for service emails which warn them if the service
is going to be changed or taken off line.
b) You display some kind of automated statistic which shows how reliable
the service has been in the past - this gives potential users some idea
of the reliability that they can expect.
That's probably enough for now.
Cheers
Joe
**************************************************
For mcg information and to manage your subscription to the list, visit
the website at http://www.museumscomputergroup.org.uk
**************************************************
**************************************************
For mcg information and to manage your subscription to the list, visit the website at http://www.museumscomputergroup.org.uk
**************************************************
**************************************************
For mcg information and to manage your subscription to the list, visit the website at http://www.museumscomputergroup.org.uk
**************************************************
|
