Recommendations For Mobile API Design

Building a high performance, reliable mobile backend is just as essential to the user experience as the design of the application itself. While building a full mobile backend stack requires more than just the API, the API is the external face on the internals and critical to both performance and usability. These 7 recommendations will help you design a better API for your next mobile cloud application.

1. Build your API to support a variety of devices

From phones to tablets and third-party integrations, the best API is one that is designed to work across a variety of devices. Not all devices may have GPS available or enabled, so ensure that your APIs can support feature variations from each device.

2. Data Size and Call Counts Matter

The amount of data you expect to send and receive from the target devices impacts the perceived performance of your application. This means being aware of how much data you are sending and the number of API calls required to get something done. Not all data connections are the same, so the more data you send the longer it will take the device to receive and process the result. Your API may perform well over a wireless connection, but may frustrate users over 3G or 4G LTE networks.

3. Model Workflow Behavior, Not Data

Many web/API frameworks, including my favorite ones, often focus on delivering APIs around data. These CRUD (create, read, update, delete) operations may work for some situations, but generally an application is more than just reading and writing data. APIs designed to model application and user behavior are generally faster, as they reduce the number of API calls required to get something done (refer to Recommendation #2). They also are easier to understand and reduce troubleshooting time.

4. Secure Your API

Always apply SSL encryption to all of your APIs to prevent leaking secure information. Also, be sure to embed your access token into the headers or as POST parameters rather than part of the URL. URLs are often kept in browser histories and server logs, making it easier to compromise an account or the entire system.

5. Build in Multi-Tenancy From the Beginning

While you may be constructing an application that is designed to work for one customer or purpose, building your API to support more than one tenant (i.e. customer) up front takes only a little more work but can save lots of time and money in the future. I’ve seen too many clients spend money trying to add it in later, slowing down progress of the product and introducing opportunity for competitors to gain an advantage.

6. Create Message-Based APIs

Every request and response within your API should be a message, generally in XML or JSON format. By making your requests messages rather than simply POST parameters, you can easily queue incoming messages that need to run later, transform them to work with other APIs, and route them to multiple systems or sub-systems within your application (e.g. billing or auditing). It also makes it easier to swap-out specific APIs with other technology platforms for improved performance or special purpose implementations, as the message format becomes the standard data interchange format.

7. Separate the API and Web Application

Some frameworks make it easy to add XML or JSON-based APIs alongside web request handling. This feature often looks like an easy way to handle both web and API requests in one place. The problem is that handling a web request often requires a different approach than an API long term. API requests should be messages (Recommendation #6), not parameters as browsers provide. Instead, build the API separately and call it from within the web application. This will force your API to reduce the number of API calls required (Recommendation #2) and model application behavior rather than data (Recommendation #3). It also enables you to scale your API tier separately from your web tier during peak mobile usage times.