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
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.