Recently I was working with Azure API Management creating an API and I needed to create an operation which would return some relatively constant/static data. Lets say for example this was some configuration data such as a list of settings an app could use.
With this scenario the challenge is how to implement the solution without having to write much code and making something which will perform well and which will be easy to maintain. I quite like the solution I came up with so wanted to share it.
- First off I created the JSON which contained the setting information I wanted to return.
- Next I saved this as a file in Azure Blob Storage
- I then got the SAS key to be able to access this this blob
- In APIM I created an operation and used the url rewrite features so that I could change the url from APIM to the blob storage url
- In APIM I can use the SAS key within the url to provide the security for accessing the file
- When my API consumer accesses my API then they are returned the json from blob storage as a response from my API
The below video will walk you through a demo of this approach:
Some architectural things to consider with this approach:
Blob Storage:
- Blob storage is an easy place to hold json for API responses
- Blob storage is going to be fast and scale well
- We can use the SAS key to specify the lifetime that it can be accessed for and easily change it behind the API proxy
APIM:
- APIM will provide a user friendly and easily accessible way for an application to get the settings
- APIM allows us to implement security scenarios if desired
- APIM can allow us to implement caching
- APIM adds lots of added value features beyond simply allowing access to the storage file
Where might I use this approach?
A few different places we might use this approach include:
Configuration Info
In the video I was trying to simulate the scenario where I needed to provide some configuration data from a central source without all of the complexity of a backend database and custom code to access it.
For anyone who works in an integration space im sure you can see loads of places where this could be handy.
Test / Stub Data
When developing a new API it is often challenging to work out what the data will look like until the development effort is well under way. Using this approach you could put together your API scaffolding and simply make it return dummy responses using json held in files. This would let your clients work against this test data while your working on developing the actual API.
Also when developing an application this approach could allow you to stub out a complex API by creating a copy of the API proxy but changing the implementation to just return dummy data from files in blob storage.
Static information that doesn’t change often
Sometimes you have organisational data which changes infrequently but doesn’t really belong anywhere yet you need to expose it via an API. Let’s imagine a list of the addresses for all of your offices. If you don’t have a central directory application you may not really have an app which is the master of this data.
In this case you could simply hold the data in blob storage and expose it via the API. On the odd time that it does change, it would be easy enough to modify the json in the blob.
