I'm building an app and found that thinking about the API from the get go made me design the app better. Why? Because the interface I'm building is just one example of how to interact with the API. The API is better and I understand my app better.

I agree. Ideally, the API you end up exposing should be something that you're already using to build services on top of yours (plus or minus a few modifications).

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.

I think it's way too early for an API, and here's why:

- 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.

Building your app on your on API or at least having your API always on your mind while planning your app is not a bad idea. It will definitely help you to get a well structured app. Might be difficult to squeeze it into you app afterwards.

Unless you use your API as the core of your own interface development. We do this at Yahoo.

Yep, I see what you mean that most usefulness to the most people is most important.

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.

Good luck, hope it works out :-)

I would recommend checking out Tom Coates' "Web of Data" talk. Presentation: http://www.plasticbag.org/files/native/ Audio: http://www.webuser.co.uk/carsonworkshops/TomCoates.mp3

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.

Interestingly, I was wondering the same thing!

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.

hey nice site... why do i have to login, though?

Cheers.

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! :)

Maybe working out the API will allow you a good second angle into how your app should interface with the world (next to the user interface, obviously)?

This is an excellent point. Thinking about the API has led to several ideas for more community-driven features.

The purpose of an API is to provide a way to build an application. If you build your website on top of your own API, then you've already shown off what you can do with your API, which is great.

If your application is something for whom an API is useful, then encapsulate the application behind your API. This will allow you deal with the application at a somewhat abstract level, which will lead to better programming practises. So, write your tentative API first, program for the API, test with rough mock-ups, then write the front end.

I think I agree with the people saying it can be good to develop your API in tandem with your app. However, I think that developing the API first leaves one in danger of being perfectionist and stops one adhering to ancient proverb, "Just fucking ship."

Nah. Let's say you want to retrieve an artist from a query string.

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.

Yes, I guess you're right that the simpler functions are straightforward to APIze.

An RSS/Atom feed is usually fairly easy to build and can make for a decent read-only API. You can add your own namespace or use microformats for app-specific data.

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.

Yes, an RSS feed of recommendations is definitely in the works.

That's a read API, then - it's a fixed URL that returns XML results... You might not need an API outside of this at all, unless you want to allow write operations.

Most of the plans I have are, indeed, based on GET commands. However, I do have ideas around post commands e.g. sending back an assessment of the quality of a recommendation.

If you're using MVC or similar framework then adding an api is a simple case of adding some alternate views. Adding these is a handy way to check if you're keeping your code all neatly partitioned.