My first task as a software development intern at Epimorphics was to create a Python API wrapper for the FSA Food Alerts API (https://data.food.gov.uk/food-alerts/ui/reference). This wrapper makes consuming the API much easier and allows users to process and analyse the data the API provides without having to worry about the details around accessing the API.
Epimorphics has created and manages more APIs that could benefit from having a Python wrapper built around them. Though it is possible to manually create a wrapper for every single one, it would be very time consuming (and tedious) to do so.
Fortunately, the process involved in creating a wrapper for any given API is predictable enough that it can – to some extent – be automated. This is what I aimed to create in this next task: a Python API wrapper generator.
Implementation and Challenges
The idea is that by parsing an OpenAPI specification, we can obtain enough information to generate some Python code that would wrap around the API. This is true for the most part, however, there is some key information missing from the spec: 1) what components in the spec correspond to what Python class in the wrapper and 2) what Python class each endpoint returns. This is made more challenging by the fact that the API specifications themselves are generated automatically by Epimorphics’ internal tools, which leads to a less predictable set of endpoints and components.
To solve this, a configuration file is provided to the wrapper generator which supplies the missing information. This configuration file is generated by having the user interact with a command line tool (CLI). This allows for a mix of automation and user input, as the program attempts to fill in the missing information on its own but also allows the user to make any changes they want.
Aside from generating the wrapper, the program also generates tests against the resulting API wrapper. This adds a layer of assurance that the wrapper is functional and makes debugging easier if it isn’t.
Ideally, the wrapper generation process would be entirely automated, and this could be a point of improvement in the future. One approach to this could be to modify the API spec generation process to include the missing information.
Another possible action for improvement is consolidating the test generation process to allow it to handle special cases that remain untested.
The code I worked on for this part of my internship is at github.com/epimorphics/api-wrapper-generator.
This project, and indeed the entire internship, has been a wonderful experience. I can undoubtedly say that the internship has helped me grow as a developer and as a professional.
More than that, Epimorphics is filled with incredibly talented and unbelievably kind people without whom this internship would not have been so memorable. I felt home (I physically was, it was a remote internship) and welcome from the first day and for that, I’d like to say thanks to everyone at the company.
You can read about the first part of my internship in my other blog post.