APIs APIs Everywhere

APIs (Application Programming Interfaces) are everywhere. Up until a few years ago APIs were most commonly used to allow third parties access to up-to-date data, and to allow CRUD (Create, Read, Update and Delete) operations between web based systems.

More recently APIs have been used to facilitate Separation of Concerns (SoC). This is where the layers of a piece of software are kept fully separated so that they can be specialised for their purpose, and even fully replaced independently of each other. A common example of this is a mobile “App” where it is very common to have the interface built in the native language (i.e Objective C, Java) or HTML5, and the actual functionality is provided by an API. The separation allows the API to be built in almost any language, or perhaps provided by an existing service such as Facebook or Twitter.

Even more recently we saw the introduction of Single-Page Applications (SPAs), where a single HTML page is loaded, and Javascript is used heavily to modify that page and provide a dynamic interface. SPA frameworks such as Angular and React make use of AJAX requests to interact with a back-end API, which is where any persistent data is stored and retrieved for the SPA.

How to Make APIs and Influence People

“This sounds like twice the workload!”, you would be forgiven for thinking, however it is not necessarily the case. I am going to take you through a case study where I saved a lot of time creating multiple APIs.

Recently I was asked to develop a new tool for one of our existing websites, the site is built using Zend Framework 2 with MongoDb as the database. As usual when building a website of this nature, I had used Doctrine 2 as a Database Abstraction Layer (DBAL), this allows rapid development of the data-bound Entites required for the site.

When discussing the specification of the new tool, it quickly became clear to me that it is a perfect candidate for a Single-Page Application. I did some research on SPA frameworks and decided that Angular was the best option for this tool (not least because I have used Angular in hobby projects before). Once work had started it didn’t take very long to get to the stage where I needed to store and retrieve data, I needed an API, in fact several APIs for the various types of data used by the tool.

I did some searching for the best way to add an API (or APIs) to my existing website, this was likely to be quite a big job since there are many facets to developing an API :-

  • Authentication
  • Content Negotiation
  • Versioning
  • Documentation

However, I was in luck, because my website was written using a popular Open Source PHP framework I had access to the vast array of Open Source libraries that are built and maintained by the PHP community. In this particular case all I had to do was install the following libraries using [Composer] (A brilliant dependency manager for PHP) :-

Once these libraries were installed and configured into my existing website, I had access to the Apigility API admin panel. Using this admin panel I created a new REST API, and with just a few more clicks (thanks to ZF Apigility Doctrine) able select a Doctrine Entity as my data source. I had a REST API working in just a few minutes, and I had the hard work done for me. Apigility handles all of the Authentication, Content Negotiation, Versioning and Documentation. Apigility Doctrine handled the data retrieval and storage, and Doctrine Query Builder provided a way for me to fetch any data I wanted via the HTTP query string. I really didn’t have to touch any code at all.

So I created all of the APIs I needed in the same way, and went back to finishing the tool in Angular, happy in the knowledge I had created all of the APIs I needed in just 15 minutes!