I'm building a music recommendation web app and I've just started creating an API (http://theperceptron.com/api) for it. However, is this too early? The very core of my app is there, but there is plenty on my todo list (I'm only a week into development). What priority should I give the API?
Also, check out Joshua Bloch's excellent presentation on how to design a good API: http://video.google.com/videoplay?docid=-3733345136856180693. One interesting point he makes is that you should avoid exposing a public API until you've successfully built three clients for it.
- API's are generally only interesting if there are already some users, accounts, etc. to interact with.
- API's are not a main feature of the site (I could be wrong here of course) and are quite a way down the list. Fix the obvious problems first. I searched for Dire Straits and got no results.
- API's aren't used by a lot of people.
Basically what I'm saying is that you should get your priorities straight: An API has no value before the rest of your site works well, and has a lot of users.
However, I'm not really too worried about artists missing from the index. I am building up the list of included artists very slowly because I only use information sources that I think provide useful recommendations. Thus, the artists that are pulled into the index is somewhat random. The comprehensiveness will grow over time.
It explains that the data is the web site (app), or at least the most important part of it. By building a web app on top of an API you are immediately exposing the unique and interesting part of your service, the data.
This leaves you, or anyone else, free to build whatever interface on top of that data. At Yahoo we absolutely use our own APIs internally to build our sites. That means most of the APIs we make publicly available are the ones our own developers have been using.
I wouldn't call what I'm doing much of a web app (http://scribbleit.net), but I wanted to learn some basic PHP so I decided to create a to-do list app (wow, new idea huh?) because I hate all the alternatives out there.
I had just finished hacking a bunch of PHP scripts to get all the functionality and then a friend of mine said, "Hey, I actually want to use this... if I could make an iPhone app for it!"
Long story even longer (sorry), I've started implementing an API just because I think it's the right thing to do. It's allowing me to understand my application a bit better and proving to be a great learning point for me.
In generality, I can only see an API introduced early as a major advantage. It can give you a direction for your design and future development. Oh, yeah, and the purpose of the API .. it will allow people to interact with your application in ways you possibly didn't imagine; there'll always be someone out there who would be interested in playing about with it!
Just my $0.02. Sorry for rambling.
How do you mean why do you have to login? It's just a little to-do app, like Remember the Milk or Tada List. You sign up, log in and start adding things you want to remember. Keeps things private.
I only built it for myself and haven't actually told anyone about it until I pasted a link here in the last comment. Thoughts and comments are welcome! :)
First, define your API for this:
external->getArtist(string)
Now program the getArtist function. Then make a gui that uses this function, deploy it and you have already shipped your first version with a single API function.
It might also make sense in your app as the more common "subscribe" use - a user might subscribe to get recommendations for new artists that fit her taste etc.