API centric development

I’ve just finished planning out the development process for a new project that myself and two friends are working on. I’ve decided to take a much more API centric approach with the development than I normally would with a site. By this I mean that I develop the API first.

This is definitely not a new idea, however, it’s one that in the development community seems to be discussed a hell of a lot less than I thought it would be. In an ideal world, new sites would follow the same development routine, unless of course there are some major drawbacks to doing this that I haven’t yet thought/found out about. We hsall see…

Why?

The main reason for this decision is the fact that at the end of this we will have a fully working, completely capable API. Now, whether we actually enable all of the options (such as user registration) through the API for third-party apps is unknown at the moment. However, for our own application – the option is there.

Also, we will have a well maintained API. One of the worst things about APIs on a lot of sites is the fact that they lag behind the site in terms of features. We’ve all been in the situation where a site rolls out a new feature or process, yet the actual API can’t do that, or allow you integrate with it.

One final reason that we’ve chosen this is that it should increase the speed of overall development. If we were to develop the site interaction and then plug an API on the side of that, we’ll probably spend twice as long developing (although, probably closer to 1.75 times as long). This is quite a huge saving in time so that we can do other things such as eating Pizza, fumbling with the frontend or simply drinking, (realistically, we’ll be developing!).

It’s A User Experience Wet Dream

One thing that people rattle on about is the fact that we should look after the users, the fact that we should give them the best experience, and that they should have the user experience wet dream that they deserve.

Giving the users the option to interact with the site through whatever means they want from launch is only going to make the site better. The fact that even if we don’t launch with an app for every device that someone out there will hopefully embrace our site & API, and push out a mobile app for that device.

The other thing is, this gives us a huge amount of scope to spread everything. We can move our site to a separate server from the API server or whatever we want. With this option, we can move everything around, without having to worry about changing two different sets of code that interact with our databases etc