A couple of weeks ago, Mubaloo’s head of technology, Ben Reed, attended the Business of APIs Conference hosted by Mashery in London. Ben shared his thoughts on the event below.

At Mubaloo, most of our bespoke enterprise apps integrate with at least one back-end system, if not more. These are often systems we’ve built ourselves, or that the client has built. However, more often than not, we find that the relevant systems don’t exist at the start of projects, which means we collaborate with clients to help them build mobile-ready back-end systems and APIs.
Good API design is integral to getting data to the apps we produce, though surfacing data can be a bit of a minefield at times. There are a number of factors that can cause issues in surfacing data, such as working with legacy systems and working around data security policies to name a couple. As an enterprise mobility company specialising in apps designed to use lots of data, we get involved in all of the aspects of API design and build. This involves a large amount of consultancy work around API design and helping to inform clients how to build and utilise them.
Those in attendance at the Mashery conference were championing APIs as much as we do. David Frankel from EDGAR Online gave a brilliant talk on how APIs should be a primary channel for most organisations. David argued that websites and apps should be secondary to creating APIs. Coming out of the talk, it was great to see that people are starting to really think about their APIs now and how they are not only useful but also integral to mobility.
Spinning Data Into Gold — David Frankel, EDGAR Online
One of the reasons APIs are so powerful is that they aren’t tied to a specific UI, operating system or device. This means that JSON or XML feeds can truly be cross-platform, something we see as being important with the rise of BYOD in the workplace. The same data can be used in a mobile app, on a website, TV app or even for machine-to-machine (M2M) communications.
If you are a technically minded person it’s best to imagine an API as a ‘model’ in the MVC (Model View Controller) design pattern. You should be able to update the presentation layer of an application without many (if any) changes to the data model itself. Likewise, with a robust API, you should be able to implement new applications without changing your data source.
Devices and operating systems will come and go, but your data and how it is accessed should not need to change as new devices come to market. I hesitate to say a good API will future proof your organisation (in technology, things are always evolving), but it’s a very good step to take towards it.

What makes a good API?

An API should be an extension to your existing architecture – nobody is asking you to replace any part of it. A well-designed API should remove barriers and enable developers to concentrate on building great applications; whether they are internal or external developers. An external agency should be able to work with your API as easily as an internal team.
Kevin Flowers, CTO at Coca-Cola, talked about how the company made the decision to treat their APIs as public-facing, even though most of them were only for internal use. I think this is a great idea. Doing so means you are ticking off things like security, scalability and documentation, very early on in the process. Internal projects are often the lowest priority for most businesses and therefore dont often get the time they deserve. Unfortunately when this happens, it can end up being costly to retrofit at a later date.

Security & Scalability

By treating an API as if it is public facing, developers can really consider things that aren’t always a priority for internal projects. These can include things like access rights or scalability for example. API key management to manage the data you are choosing to share is an important factor when thinking about securing APIs. API keys provide a central method of restricting access to the data.
No company will to want to expose all of its data. To work towards the same strategy as Coca-Cola, the best thing to do is to create a mock application to show what data the API will surface. This will give the IT team confidence that the data is secure and worth surfacing. Other recommendations included holding internal hackathons to see how data can be used in apps. By using systems from firms such as FeedHenry and MobileIron, it is possible to secure the APIs for internal apps only.
In terms of scalability, the best thing to do is to test a number of different scenarios. Load test your APIs to get an idea of how your infrastructure will stand up to the traffic. Even if your API is closed to the public at first, it will be a good exercise so you know what to expect should you open the APIs. Alternatively, it’s also worth testing incase the API experiences more internal traffic than expected.
Based on our experience with APIs, and the outcome of the conference, here are a few top tips:
  • Documentation is essential to a good API
  • The barrier to entry should be as low as possible
  • Security shouldn’t get in the way and a developer should not need to understand your corporate network architecture in order to use your API
  • If your API is public facing people simply won’t bother if it’s not easy to implement
  • If you do already have APIs, make sure they are well designed as this will make working with external agencies much easier
  • If you don’t have APIs, it’s worth investing in them and putting the effort in now to avoid delays and extra costs at a later date.
At Mubaloo, we think that APIs are going to become more and more important in 2014. We believe there will be a rise in the amount of data consumed via APIs rather than web pages. We are moving more towards a world of thin clients and APIs. The API is the key to moving in this direction. So get your APIs in order and you will find the transition to apps and future technological evolutions much more straight-forward.
By Ben Reed, Head of technology

Join Our Mailing List

You have Successfully Subscribed!