Kristo Vaher has an interesting post looking at a development technique that's becoming more and more popular among web applications - API centric design. More development is being focused around reusable APIs than just making applications. Kristo fills you in on a few things you need to know about this technique and some things to watch out for along the way.

Modern web applications are often anything but stateless and consist of layers upon layers of session handling and asynchronous requests, where users can log in and their functionality is dependent upon dozens of checks before a page is returned to their web browser. In order to manage this problem a little better, we have to take discover - or rediscover - something that has existed in desktop software development for a dozen years: API-centric development and design.

For those new to the topic, he explains what an API is and how centering your development focus on it can help in the long run. He suggests that the API should be the software and everything else - clients, outside users, etc - just interacts with it. Some solutions are offered to help encourage this development including:

• Using a MVC (Model/View/Controller) structure
• Starting from day one to develop the API
• Planning before writing any code
• How teams should be working together, but on different elements

On Reddit.com there's a recent post talking about an API-centric architecture that would separate out business logic from user logic.

I'm in a fairly unique position of being able to refactor an existing site that gets a moderate amount of traffic (~10k per day). Technically speaking, it probably does not NEED to be rebuilt from ground up, but as this is somewhat of a hobby project for me, I am choosing to rebuild it because I think there are significant long term benefits and because of the learning experience it affords me. [...] The solution that I've come up with, so far, is to create a single library whose sole responsibility is to handle system / business level interactions that occur. This API is completely segregated from any consumer facing frontend and de-coupled from any particular framework implementation.

Comments on the post are mostly supportive - they're in favor of the API-for-business-logic approach, but some recommend other methods than the single library attack. There's suggestions of using current frameworks to handle some of the "dirty work" involved in setting up the API and a mention of focusing on performance as well as functionality.