If you are building a mobile application, it’s likely that you’ll end up implementing some form of a backend integration to make your app work. Although there are some mobile apps that live on isolated islands of connectivity, most apps need to talk to backend servers to deliver the user experiences that modern users want.
The need for backend connectivity stems from the constraints of the mobile device itself. While portability is a great convenience, it has given rise to limits on power, CPU processing and storage within devices. Of course, portable technology continues to improve, but offloading intensive processing, large data storage and battery intensive activities to backend systems is often the most cost-effective and resource-efficient plan.
Beyond performance and efficiency, application users are demanding a more connected experience from mobile applications. They want to be able to easily interact with the digital world around them without having to leave the application space. They expect the data that drives their experiences to be synchronized, regardless of the platform they choose or the application software they install and run.
In all of this, the touch point for the mobile app is the interface or API that a backend system provides. It is the API that provides the hooks that allow apps to easily implement programs that can live within the constraints of portability. APIs are what facilitate the connectedness and synchronicity that mobile users desire.
Powering Experiences with APIs
The term API is generic enough that it doesn’t provide any real information on the mechanism for connecting to the backend, only the fact that an invokable interface exists. Developers have many design choices to make when implementing network-based APIs, but generally speaking, data-oriented web-based interfaces, sometimes called “RESTFul,” are the most popular. These are interfaces that are accessible via HTTP and are easy to call from mobile platforms.
API thinking has permeated the mobile design space enough that “API-first” design strategies have gained popularity. Designers adopting an API-first strategy focus on the design of the API that sits behind the mobile application before building the app itself.
This is really an extension of the “mobile-first” movement that has inspired UX designers to build specifically for the smaller screen rather than scaling the desktop experience down to size. By focusing first on the APIs that power the mobile app, a similar shift in design priority is prescribed. An API-driven mobile app moves business logic, presentation elements and processing to the backend, behind a well-designed interface.
A major benefit of driving app behavior or presentation for an API is that the app itself will require less change. Changeability of mobile applications has always been a concern, and while it is certainly easier to deploy changes to software today than it was many years ago, there is still a high level of friction involved. Backend systems and APIs remain in the developer’s realm of control and can easily be updated.
In addition, focusing on API design makes it easier to deploy an app to multiple platforms and operating systems. One of the advantages of a Web API is its language independence. As processing, storage and UI components are shifted to the backend and delivered by an API, the front end app code is reduced and the barrier to migration becomes easier, as there is less work to be done when porting the application.
Of course, it is important that the app designer doesn’t rely on a backend to the point that the design suffers. We still live in a time where networks are imperfect and bandwidth is limited. Good applications know how to cache responses, minimize network use and call APIs based on the bandwidth they have available to them. Ultimately, any problems with the latency or reliability of a backend API shouldn’t be reflected in the actual end user experience.
Designing and developing backend APIs can be a great way of powering a mobile experience and it doesn’t need to be a do-it-yourself job. Over the last few years, a wealth of third-party APIs have popped up on the web. These APIs allow mobile developers to easily incorporate new functions into their app, including the use of data and services that may have been closed to them otherwise.
The Web has emerged as a platform for developers to provide richer experiences for their users. Today, one can easily build an app that incorporates social networks, music, video, cloud data storage, text-to-speech processing, voice services and image processing without any heavy lifting; all that is needed is the code to make the API call.
Incorporating a set of third-party APIs can greatly reduce the development cost of applications and allow teams to spend the majority of their time on the logic and features that will differentiate the application in the market. Of course, if it is a struggle to write and maintain the code that uses the API, these savings disappear.
The good news is that API owners have taken the idea of building developer-centric interfaces to heart. More time and energy than ever before is being spent on building Web-based interfaces that are both easy to use and easy to get started with. In addition, the rise in popularity of APIs has created a competitive market. Sought-after functions like mobile payment, voice communications and geo-location are provided by a large number of suppliers, resulting in competitive pricing and higher levels of usability. It’s a great time to be a developer.
What’s in it for API Owners?
Of course, most API publishers are not philanthropic organizations providing interfaces just to improve the prospects of mobile developers. The majority are released by businesses, which create API programs hoping to increase their long-term profitability. One of the biggest drivers for APIs targeting mobile developers is the opportunity for the owning organization to reach more of their end-users. Direct revenue is also a popular driver for API programs and is manifested by asking developers to pay for use of the interface.
The best revenue-based APIs provide clear pricing, great support and make it very easy to get started. When signing up to use this type of API, it is important to consider not just the cost of usage at inception of the app, but also the implications of success. What would the cost be if the rate of API calls suddenly increased from 10 a day to 1000+?
APIs focused on consumer reach hope that application developers will leverage the API that is offered to bring their product or service to platforms that they are not able to serve. For example, iOS and Android are frequently well-supported by product managers, but other platforms may be neglected. By opening up an API, an organization may be hoping that a mobile developer will create a suitable offering for operating systems like Microsoft Phone or Blackberry. In these cases, it is important for prospective API users to carefully examine the terms of services for use. There may be surprises lurking within around advertising, revenue generation and usage of data and images.
Utilizing a third-party API is a great boon for application development, but commercial app developers should view this type of integration as a business partnership. It is important to understand the motives of the other party, the risks involved and to have a contingency plan for unforeseen eventualities.
Security is Hard Work
While API providers are making great strides in usability factors for developers, security implementations present a speed bump in the development process. Developers writing code to invoke a Web-based API will quickly encounter privacy controls, access control mechanisms and secret keys designed to protect the backend system.
The nature of the public and open Web makes security a necessity – especially in cases where data is valuable or money is being exchanged. In the past, API implementations each had their own custom security controls, greatly increasing the learning curve to get started. However, we are now fortunate enough to have standards like TLS, OAuth 2 and Open ID Connect that may help reduce the effort in the long run.
These specifications aren’t simple to understand or easy to implement, but they have opened the door to tooling, libraries and abstractions that can reduce the technical challenge of writing clients. Mobile developers who plan to use third-party APIs should have at least a passing knowledge of these standards and choose a library that will safely and effectively support them.
APIs Wrap Up
The world of Web APIs is providing a tremendous opportunity for mobile app developers to build rich user experiences with the flexibility to change and expand the offering. When embarking on an app project, it makes sense to use backend APIs to power the app and search for third-party APIs that will enhance the functions that can be provided. The days of isolated, unconnected applications are almost over.
Are you paying more taxes than you have to as a developer or freelancer? The IRS is certainly not going to tell you about a deduction you failed to take, and your accountant is not likely to take the time to ask you about every deduction you’re entitled to. As former IRS Commissioner Mark Everson admitted, “If you don’t claim it, you don’t get it.
Get hands-on experience in performing simple to complex mobile forensics techniques Retrieve and analyze data stored not only on mobile devices but also through the cloud and other connected mediums A practical guide to leveraging the power of mobile forensics on popular mobile platforms with lots of tips, tricks, and caveats.
The Chirp GPS app is a top-ranked location sharing app available for Apple and Android that is super easy to use, and most of all, it's reliable.
Write and run code every step of the way, using Android Studio to create apps that integrate with other apps, download and display pictures from the web, play sounds, and more. Each chapter and app has been designed and tested to provide the knowledge and experience you need to get started in Android development.
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.