After receiving the initial request to implement a new API proxy, usually by a product owner of another team, we have a detailed look at the request during a team-refinement meeting.
In this meeting we will have a look at the delivered openAPI specification (documentation about the new service) and scan it for irregularities based on the company API conventions. We usually find some irregularity and send them our feedback in either an email or through comments on a merge request in a designated git repository used for such requests.

When the feedback has been incorporated and approved by our team (integration team) then I can start to implement the API proxy in Apigee.

This process starts by creating a new repository where the code will reside for this proxy. In this repository I will create several branches to match the different environments that we work with.

In this case that is a development, test, acceptance and production branch. The starting point of any new API proxy is by copying a skeleton project into the new repository. The skeleton project consists of overlapping features used by every API proxy in our organization. Then I will have a look at the openAPI specification provided by the backend team and make some adjustments so that it matches our company standard. For example, I adjust the URLs so that it points to our API manager instead of the backend, add certain error codes specific to what the API manager can throw, contact details and add security parameters.

When the documentation is fully compliant, the API proxy can now be built. Looking at the openAPI specification, I will implement the HTTP paths with corresponding verbs (POST, GET, PATCH etc) in our API manager. Usually that is sufficient but sometimes the client would like to implement mediation or do other forms of transformation before it is sent to either the backend or returned to the client. In that case, I will implement the requested features by utilizing API manager policies.

Now that the API proxy is done, it still needs to be properly tested. We use postman scripts to do so. For every path there are specific tests that must be implemented to meet our company standards. We test the functionality of our API manager, but also several things in the backend application. For example, what happens if you don’t send any message body when it is mandatory to do so? Or what happens if you don’t send any security parameters such as an oAuth token? If all the test cases succeed, then we will add these testcases to the repository and push it to GitHub.

I then create a new pipeline for the new repository so that every time a new change is pushed to development or any other branch, the pipeline will automatically run and push the new code to our API manager and test is thoroughly. After that is all done I need to document the new API proxy with it’s paths to a documentation section within the company so that other colleagues know of its existence and are able to use the new service once live.

The only thing that remains now is a cross check by my colleagues of the integration team. If he/she spots something that has to be adjusted then a comment will be placed on the pull request going from the development branch to the test branch. I will fix these issues and let my colleague know it is ready to go to the final check by our product owner. Once that is all cleared we let the backend team know we are ready for a deployment to production whenever they are ready. Then, at a scheduled date and time, our production environment manager (AppyRuns) will deploy the proxy to production and then it’s a wrap!