From Zero to API in One Working Week

A day-by-day guide for your mobile app development team

In software development, some projects require extreme agility. Your team is now required to stand up a mobile API in one week. This can be intimidating for even the most experienced team.

Take a deep breath, and map out your week.

Day 1: Domain/project research

Before any work can be done, understand the domain, scope, and depth of the project. Don’t rush through this process, because the resulting work is a guide for the entire project. 

Bring in all the teams who will be consuming the API: web, mobile, and desktop. Create a map of endpoints you believe will be consumed. Continue building on this map by creating a loosely based database schema. The design can, and will, change as development progresses.

The key to success during change is to be as agile as possible, without losing the overall structure. 

Day 2: Select your platform/language, and set up the environment

It’s time to select a language and platform. This selection will also help determine a location (AWS, Azure, Rackspace, self-hosted) to host. After selecting, purchasing, and standing up your server, you may need to setup basics like http, SQL server, and other server dependencies.

Pay attention to the database driving your API. It’s important that you not neglect this vital piece, since there are many options, from traditional SQL databases to NoSQL such as MongoDB.

Day 3: Authentication Strategies

Now that the server is ready, it’s time to research and implement an authentication strategy. Review all options available, as many languages and platforms have pre-written authentication modules.

Ruby on Rails has a great option in Devise, .NET utilizes built in IIS modules, and Java has JAAS. Another option is to implement your own custom authentication method.

If the team chooses to implement a custom authentication, be sure to research OAuth2 and be sure you understand the implications and security requirements.

Day 4: Write the API

Time for code, and to turn the guide into real endpoints. Start with the database and server objects and build out from there, exposing the endpoints starting with the simplest and moving out to the most complicated.

Test while developing, either through a test harnesses or with simple tools like Fiddler or Cocoa Rest Client. If something breaks or constraints restrict what the API can handle, make an executive decision and continue to move forward.

Day 5: Consume, reflect, iterate

Bring all the teams back in, and review the live API. Start consuming the API in a working session so you can fix any potential issues that arise during consumption.

Now, look back at the accomplishment of rolling out an API within one working week. Update the project documentation to ensure any changes made while writing actual code are within the documents.

Be prepared to iterate upon the design, and release as needed. Throughout the entire project momentum must not be lost, executive decisions must be made. Agile does not mean chaos; it means planned and calculated change.