API-Driven Development

[eluser]Jamie Rumbelow[/eluser]
I've written a new method of development on my blog called API-Driven Development, and it's based around the idea that all applications are built around an interface to take in data, and a back-end to process it. It simply refines the development process and abstracts the interface.

I'd like to hear the community's thoughts on this: http://jamierumbelow.net/journal/develop...evelopment

[eluser]jalalski[/eluser]
I used to work in C++ and this was an important technique, especially if we were working on a library. Almost by definition, a library has an API, which ideally shouldn't change during it's lifetime. On a large project it was essential to separate out the project into libraries that worked together through pre-agreed API's. These could, in the start of the project, just be stubs. I was quite influenced by Meyer's idea of an API being a contract with the rest of the application.

I've kept some of these habits in my work with PHP and CI. I push as much into either libraries or models, with clearly defined interfaces and stub functions in place. I often start this design phase with pencil and paper, drawing pseudo UML diagrams, or even use a UML editor. When the basic components of the application are there I'll create the class files and stub functionality. If I were using a test framework I'd probably also start thinking about test cases for the API.

Your article talks of having two people or groups taking the part of front-end and back-end, but of course if needed a lone programmer can wear two hats in the process. The back-end is the models and libraries, the front-end is the controllers and views.

A subtle twist with CI is that the controllers are based on the applications URL's, so in a sense this is another API between the user and application. It's worth spending a little time on thinking about what the URL's will be and how they will translate into the library interfaces that you've created above.

When does your book come out?