API development

What is an API in software development?

API stands for an application programming interface. It is a set of definitions and protocols that are used for building and integrating application software.

Application programming interface (API) example

APIs allow you to have an interoperable “source of truth” between your data layer (usually a database of some description) and your presentation layer (typically, this could be a mobile application or a website, or a desktop application). Let’s take the popular communication app, Slack, as an example.

Slack has a mobile application and a desktop application. Their API will allow users to be logged in on their mobile application to be able to talk to users logged in on the desktop application because both presentation layers are sending data to the same (persisted) data layer*.

*The data layer could actually be much more complex than merely one database server, but we will leave the intricacies of the data layer for a discussion at another time.

There are many types of APIs that are available to use. For example, if you want your digital product to show the current weather for a specific location, make a Google Calendar appointment or maybe provide travel updates, you’ll need to access an API service that performs these actions.

Here at Hiyield, we focus on API development that work for your idea or business needs. We always start working with you by kicking off with a discovery session, this is where we understand your current goals, aspirations and wants, as well as any frustrations, and turn them into a scoped digital product. From this point, we begin to architect your platform, so we understand what data needs to be stored, and how, and then what permissions are needed for this data.

API development for CV building web application

Here we went for a simple RESTful API. A RESTful API adheres to certain web standards around the notion of C(reate)R(etrievie)U(pdate)D(estroy) and http verbs. http verbs might also be a discussion for another day.

Putting this all together, under the hood, we have the notion of the CV, this is effectively raw storage of the User’s inputted information, including their personal information, work experience etc, and the User. The User essentially stores much more sensitive information and will allow us to restrict permissions per User. That is to say, User A can only see CVs they have created, and NOT CVs User B has created. Once a User starts building their CV, on initial save the web application will perform a POST request to, as a simple example, the /cvs endpoint. The response back will be in the form of the CV model, as well as containing a  unique identifier for this particular resource. This unique identifier allows us to perform the RUD parts of the CRUD philosophy, provided the requester (a User) is permitted to do so. This API setup will then allow us to be able to scale and extend as needed, with a very strict set of principles. This keeps our APIs clean and easy to read, DRY and most importantly secure.

API development can be done in any language or framework of our choosing

Building the API could be done in any language or framework of our choosing. That’s the great thing with APIs, is that whilst someone more proficient in Swift or Javascript could be building the presentation layer, the front end, our backend engineers could be building the API in Python, node.js or C#. For technical delivery teams, this really allows us to build at speed and react to changes in client requirements. For example, if the client decided they also wanted a MacOS desktop application, we could leverage electron.js to build the presentation layer, whilst keeping the API layer exactly the same. Let’s also say that we now want to limit the number of CVs a User can build or create, which would be dependent on how much they are paying, or not paying, for the service or product. We just need to adapt the API permissions on creating resources.

For example, if the free tier of the CV building platform allows for one CV, we can allow for that, and if said User has a subscription, we can apply a different limit from the API. With a few minor front end changes, dictated by the API layer, we can code a payment and SaaS product relatively easily if we’ve adhered to the above CRUD and permission principles of RESTful APIs.

Third-party API development services

Some of our products also utilise third-party API services. This type of integrations service is also something we love to do. For a recent project, we had the need to relay the current weather conditions back to the User to allow for them to make an informed decision about whether to book or not on the day.

However, third-party APIs can come with hurdles. For this particular API, there is a restriction on the number of calls that can be made every minute (60 per minute was the particular rate that we were restricted to). The API call for the latest weather forecast couldn’t be made on client-side (on the User’s browser). We therefore needed to make that API call server-side, through the use of a scheduled task called a cron. The latest weather data was then stored safely to the DB, every 5 minutes, allowing for a more performant load time of the website as well as ensuring we wouldn’t hit the dreaded rate limit.