Prototyping APIs for Mobile Apps
Unless your mobile app is completely self contained, it’s likely to be using a server component in some shape or form. And when front-end features depend on their back-end implementations, the app teams are left waiting for their server counterparts, wasting time and money. Prototyping can be used to mitigate that.
To prototype or not to prototype
The skeptics among us will question the need for prototyping in the first place. Shouldn’t the aim be to ensure the readiness of the APIs before any app development kicks off? In the ideal world — yes, but factors like tight deadlines, last-minute requirement changes and resourcing problems can make that impossible.
That’s not the only argument for prototyping though. Even when time and resources are sufficient, the API design may not work as well in practice as first thought.
Consider a server component originally written for a web application and now reused for native mobile apps. What works for the former may result in many unnecessary calls for each screen in the latter, which is not optimal and can be difficult for back-end engineers to foresee. The solution is prototyping the proposed changes, ensuring they work well with the apps and then handing them over to the server team to implement in production.
Basic solution
Choosing the prototyping tool for your APIs depends on your proficiency in back-end development. The easiest option is simply constructing responses for your endpoints as static JSON or XML files and hosting them on a local web server.
Improving that idea further, services like Apiary can publicly host the static responses for you. They also allow you to easily define paths to your endpoints, provide documentation for each one and many other things likely introduced since this article was written.
Advanced solution
When static responses aren’t enough, the next step is writing prototype APIs in lightweight frameworks, which allows you to add any logic missing from the static responses. It may seem slightly wasteful to create a whole new API just for prototyping, but it really isn’t, considering how little code you need to create a fully-functioning web service in many frameworks.
The choice of framework is relatively easy, because production factors like performance are completely irrelevant for a prototype and the only goal here is producing something quickly. Therefore, it’s a good idea to choose a framework based on the language that you are most comfortable with.
My personal preference are Sinatra-like frameworks. They’re lightweight and there’s one available for virtually every language in existence. It really doesn’t take much to write a working API, the code is readable and there’s no boilerplate that many web frameworks are fraught with.
Below is an example application written in Flask, the Python variant of Sinatra.
from flask import Flask
app = Flask(__name__) @app.route("/")
def hello():
return "Hello World!" if __name__ == "__main__":
app.run()
That’s it. There are no configuration files that I’m omitting, that’s the whole working application.
To go further and be able to save data, you can use a NoSQL database, such as MongoDB. There is no need to define a schema, just import the library and start running queries.
Hosting
Once your prototype API is ready for the apps to use, you need somewhere to host it. For development purposes running it on your machine and pointing the apps to your local IP address is sufficient. However, when you need to demo it to your colleagues or clients, you need something more solid.
The most convenient solution is going with a PaaS (platform as a service) provider, such as Heroku or Google App Engine. With a PaaS you don’t have to worry about configuring and maintaining your server instances, you just deploy the application and use it straight away. As an added bonus, most of these come with a free tier suitable for prototypes.
Conclusion
Prototyping is good. Although it may seem like extra work, it helps prevent deadlocks in app development and allows mobile engineers to implement and test features that aren’t yet available in the production APIs. On top of this, with the variety of simple solutions at hand, from static response hosting to lightweight web frameworks, there are options available regardless of your skill level or how much time you have.
Originally published at blog.maxwellforest.com on October 22, 2015.
