Today, the internet is crowded with informative articles on designing a flawless API that allows a mobile app to communicate with a specific web/cloud based service. While some of the concepts and practices have proved helpful for mobile API designers, others have simply faded away with the passing time. Optimizing the back-end APIs for excellent mobile client experience is something that needs to be taken into account by everyone who's looking for enhancing the overall the on-mobile performance of an application. Through this post, I'll be showcasing some of the result-proven tips on designing a fabulous Mobile API that ensures the mobile clients are served with data and app resources remotely. So, let's hop onto these tips instantly!

Ensure proper versioning of the API, right from the beginning

Since your mobile API Is bound to undergo changes at a later point of time in the future, it is recommended to opt for its appropriate versioning. Serving as the only contract between backend and the apps using it; API must come in a variety of versions. Doing this would enable you to continue using the application which is well familiar with all the latest API changes that have been introduced into the new app version. Ignoring the versioning of API would make the applications non-functional in case any kind of modifications are being made to the API.

Make the most of caching and LocalStorage

In order to prevent the negative impact of a slow mobile network on the app's performance, it is recommended to store the HTML, CSS and all the images into localStorage. There have been mobile app owners who have witnessed a reduction in the size of their HTML documents, from 200KB to a marginal 30KB. As an additional tip, it is better to ship all the unchangeable data like categories, main navigation etc. within the application. Doing this would never actually require a trip across the chosen mobile network, thereby saving you from the hassles of pre-fetching data(queries, paginated results, user data etc.) that would be loaded on the device without any extra requests.

Put JSON to use

Gone are the days when passing POST data in the form of url-encoded data was considered effective. Today, things have changed and it is advised to use JSON for sending data to endpoints. Doing this would not only make the requests a lot more readable but they would even be assembled easily by the end user. Rails has served as a quick means of handling all JSON-encoded parameters. It is Rails' ActionController which automatically unwraps data fetched by JSON- allowing you to access the same via params hash.

Pagination of Results is a must-do

Pagination is an effective technique of preventing the return of hundreds and thousands of records for numerous customers-all at one time. Hence, while designing your mobile API, do remember to paginate all the results that return a particular list of items. In Rails, you can conveniently implement pagination via kaminari or manually with the use of OFFSET and LIMIT statements within your queries or data collections. An important point that needs to be kept in mind here is that it is mandatory to display the pagination meta information when the paginated results are being returned. A viable option for doing this to use HTTP Link-Headers within the response. It is vital for you to know that this header includes full URL to the first, last, next and previous page of the result set, thereby making it comfortable for the clients to handle multiple paginated results simultaneously. All in all, simple parsing is guaranteed with the on-time pagination of results.

Avoid including unnecessary steps/requests within the API

It's quote common for mobile APIs to have individual discrete steps that showcase the way in which the service can be used in the right way. As an API designer, you must avoid including such discrete steps as most of the times, they don't serve as the right means of implementing a mobile app efficiently.

Opt for implementing a Rate-Limit at an early stage during the API design process

While things are calm during the initial days when users begin using your API, things can get out-of-control once your application becomes a huge success. In other words, more and more people would choose to integrate your API into their wokflows and infrastructure; thereby calling your endpoint and requesting the same URL again and again for thousands of times in a single hour. It is here that the concept of implementing a Rate-Limit acts as a ray of hope. A simple Rate-LImit would not only prevent the servers from getting down via CI-server but would even offer the users a clear indication on how the API can be used accurately. While for a large infrastructure, Nginx limit_req can serve as the right approach to implement a Rate-limit; for others, Redis can also work wonders.

Go with the Non-blocking IO

Talking about optimizing an API for the client, it is utmost essential to pay individual attention to blocking the JavaScript execution. For instance, if your API needs to rely on a third-party, then choosing the non-blocking IO is believed to be the right approach. You can either go for the Triggering model or the Polling model. Here's an explanation of the two models:

• Triggering model- Also called as the push-based model, the Triggering model has a trigger API wherein the call will make a request, followed by attending to the response received from the server. Additionally, a call back is provided to the server, allowing it to trigger the event and informing the caller about the availability of results.
• Polling model- Popularly known as the pull-based model, the Polling model has an API wherein the client makes a request, followed by periodically checking for the availability of results belonging to the particular request. In this model, you require a periodical backing off.

Do note that the Triggering APIs are a bit harder to implement simply because the mobile clients aren't trustworthy. Therefore, the Polling model is a better option for designing mobile APIs. By having all the data that's required for rendering a page that's returned via a single API call, you can easily avoid adversities associated with slow network connections.

The caching policy must be planned and implemented carefully

If the data that would be returned by your API won't change frequently, it is a must to implement the correct caching policies. In other words, you can opt for storing the data in memory, instead of reading it from the desk time and again. Likewise, if you're thinking about implementing caching on the server, then ascertain to render a unique way of validating the caching process easily. By focusing your efforts on implementing effective caching in the client app that uses your API, it becomes quite comfortable for you to save a good count of resources as well as your valuable time.

Assign easy-to-understand names to API assets

The way in which you name different assets of your API will have a huge impact on how your API will be understood by the users. Hence, while naming the API assets viz: objects, methods, properties etc. make sure to perform a detailed research on the right terms that would eliminate any kind of confusion related to API's accurate usage.

Authentication shouldn't be neglected for a non-public API

Hackers are everywhere. If you're heading towards designing a non-public API, it goes without saying that you need to have a streamlined authentication system in place. Unlike the typical TokenAuthenticatable strategy that was used for incorporating an authentication mechanism into the private APIs; today, it is a good idea to leverage HTTPs' Basic Authentication. Implemented in every HTTP client, this HTTP Basic authentication expects the consumer to enter a valid username and password for gaining access to the API. In addition to this, you can even allow the users to sign in to an API via private access tokens which can also be used in case of CI-server installations.

Accompany your API with a commendable documentation

Documentation is indeed the most vital aspect of your API design project. An ambiguous and unclear documentation can easily frustrate the developers to an extend that they may simply ditch your product for a different one. Hence, it is essential to provide a nice and error-free documentation that's free from lengthy code snippets. Never forget that developers simple love browsing through examples. Hence, make sure to include the same to render a good understanding of your API and its utilities. On the contrary, if you want to provide code snippets to the users, opt for including them in different test cases. Doing this will assure the up-to-date status of your documentation, each time the API gets moderated. In order to build the right documentation for your API, you can either opt for a custom-made solution or any of the renowned ready-made tools like Apipie.

Wrapping it all up

Here's hoping the above post would serve as a useful reference, the next time you plan to design an API for use by the mobile clients. Get on with following the aforementioned tips and you can design a perfect mobile API in a fuss-free way.

About the Author:

This is Amanda Cline- a professional developer employed with a leading Web and Mobile app development company named Xicom Technologies Ltd. Apart from developing eye-catchy