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.
API development for digital products
The true benefit of adopting an API is that it makes it easier to integrate new ideas into current products and makes adjustments more flexible. It can be thought of as a bridge that you can use to fetch the data you desire. For example, you might create an API service that stores and retrieves customers orders. Having these easy to access bridges (API’s) makes it easy to change and to stay flexible. As you can quickly respond to new competitors that join the scene and remain at the forefront of your industry.
How we create APIs
Here at WSM Technologies, 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.
API
Let's discuss
your ideas