Hi Ian,
Standardised: ATOM would be perfect - What is the lists thoughts on
GData?
Documented: Upcoming.org have almost no documentation at all but they
do offer a wiki. Some kind of hosting space would be handy (not for
us, but for you to host bits from us). I'm thinking of bits such as
the weather<->Place ID list etc. I say a 'hosting space' as I'd
imagine you'd have to separate it from official BBC bits.
Formats: First and foremost (for me) is XML. If I was pulling your
data in Javascript I would opt for JSON. JSON has drowned YAML
recently but YAML does address some of JSON's shortcomings and I
believe it'll come back up for air at some point. I've never found it
to be too much of a task to add alternative parsers.
Does anyone have not-so-favourable experience with YAML?
Dev System: Calls per day is going to be rather quirky in the world
of widgets - It would be a shame to see something really take off and
then break in the limelight. If it was too restrictive developers
could look at caching themselves but that's not ideal.
Authentication: To resurrect up the recent discussion; HTTPS if it's
private, key based if it's not. Then you run into distribution issues
as Neil just mentioned. The easiest, fastest solution would be each
developer having his own gateway :o/
Regards,
Gareth Rodger
W: http://www.garethrodger.com
E: [EMAIL PROTECTED]
On 7 Dec 2006, at 12:48, Ian Forrester wrote:
So it looks like,
RESTful
I guess XML-RPC lost out in everything except blogging and SOAP is
still too painful for most people.
Standardised
So for example if we embedded everything in the ATOM syntax you
would like that? Or did you mean something else?
Well Documentated.
Yep, and I really like the idea of a wiki which you guys can also
edit.
Formats.
My feelings is XML makes a lot of sense. JSON, well I know its
gotten much love recently but... YAML? does anyone actually use
this? I thought JSON did away with YAML?
Also who's offering this as a webservice?
Developer system
Yes we will require some kind of authentication system and I guess
this is where the real debate goes. What kind of interactions would
you prefer?
How would you feel about us having some developer key system,
maximum amount of calls a day, authentication?
What have you seen which you like?
I remember Flickr was a pain because you couldn't find your dev key
easily, while Amazon had a dev token and authentication.
Technorati's limit of 1000 calls a day is ok but how do people feel
about the result once you go over the limit? Should error messages
use http states or return errors in xml?
Thoughts?
Ian Forrester || backstage.bbc.co.uk || x83965
From: [EMAIL PROTECTED] [mailto:owner-
[EMAIL PROTECTED] On Behalf Of Gareth Rodger
Sent: 06 December 2006 15:44
To: [email protected]
Subject: Re: [backstage] The best WebAPIs
I must agree with the Flickr fans.
In my opinion if it's;
RESTian
Standardised
Well documented
Choice of output formats (JSON, YAML, XML etc.)
An open wiki to supplement the docs
It'll do for me.
Will the BBC require developer keys or authentication?.
Gareth Rodger
W: http://www.garethrodger.com
E: [EMAIL PROTECTED]
On 6 Dec 2006, at 12:58, Neil Roberts wrote:
>>which API's have you used which were a joy to use and why?
I really like the flickr because they offer a simple api for non-
techies in the form of the badge, which even my dad can use (this
is a man they type with one finger and that's not one finger on
each hand but just one finger).
This makes the content really accessible which is important.
And on the other end of the spectrum they offer api's that for the
true developer that allow you to achieve things like this
http://www.webmonkey.com/webmonkey/06/08/index4a_page2.html
For me this is awesome becuse it not only shows their content up
in a good light.
It promotes flickr and can inform their service development; all
things that I think backstage is trying to do for the BBC.
Important things that I have found useful but may not fall into
the realm of api for some people is:
For the novice:
Restful/guessable/hackable URLs
A range of simple standard RSS feeds
Examples and easy to use interfaces eg: flickr badge
For the not so novice:
Parameterised RSS feeds
HTTP implemention is always good but the technology in my opinion
should be the one that can be used by the most people.
Good documentation and often the best documentation is not found
on the providers site but on people's blogs, so making the
documentation an open wiki would help.
neil
On 12/6/06, Mr I Forrester <[EMAIL PROTECTED]> wrote:
Right Calm down everyone! :)
Lets put the debate on hold for now (although I was tempted to
throw in
a line about the GPL3 drafts). I don't know about everyone else,
but I
personally think this could make a good podcast if I got a few of
you in
a room together.
Anyway,
Its almost 2007 and I wanted to ask a question to the list.
One of the things you really want more of, is more BBC API's. Well
were
working on that but I wanted to ask which API's have you used
which were
a joy to use and why?
Is the documentation, API naming, structuring, amount of data
given away
or something else?
For example, for me Flickr's API is great but I love the security of
Del.icio.us. The documentation on Flickr is also very easy to
follow and
understand while the ability to run XSL serverside on Amazon's
servers
has been useful. Google Data/Base is very interesting being just ATOM
based and I can certainly see more APIs using ATOM as a base result
response in the future.
Don't worry guys we can pick up the Free Software debate later...
Ian Forrester | backstage.bbc.co.uk | cubicgarden.com
Laurence Samuels wrote:
> You explained these a long time ago, and you kept on repeating what
> did not amount to new knowledge. I hope you wont reply to this
email.
> If you do, I wont reply to the list, I might reply to you
privately.
>
> L
-
Sent via the backstage.bbc.co.uk discussion group. To
unsubscribe, please visit http://backstage.bbc.co.uk/archives/
2005/01/mailing_list.html. Unofficial list archive: http://
www.mail-archive.com/[email protected]/
--
"I like work: it fascinates me. I can sit and look at it for hours."
