Reference: Part 1, Part 2, Part 3, Part 4, Part 5
Returning to our application we know have a service, sitting behind an Azure API Manager (APIM) that requires a token to access. The APIM layer can also be used to enforce rate limiting and CORS rules, as well as other common API features. Additionally, this feature gives us access to a couple portals where we can administer the API and even provide users with self service for getting tokens.
Now, we are going to add our final endpoint which performs a GetAll for our data. This is similar to what we did in Part 2 when we created the Upload handler, though it will just peform a read against our Cosmos (Mongo) table.
Create the endpoint in Visual Studio
One of the things I like about how Microsoft has approached Azure Functions is the solution based approach that Visual Studio helps promote. Unlike with Lambda, your functions are not simply floating but can be easily grouped.
In this way, I recommend opening the SLN file which holds the Upload endpoint. You can right click on the Project and indicate you want to Add a new Azure Function.
This will walk you through the same sequence as before and again you will want to create an HTTP Trigger.
Per the convention laid out by REST we are going to want to ensure that our endpoint responds to a GET verb. We can use Anonymous for security. (Note: this does NOT control whether a token is required or not, that is controlled by APIM).
Here is some code that I wrote up that selects our results from Cosmos, its all pretty straight forward.
Now we can Publish our project and see our new function in the Portal. Now, we need to add it to our API.
Adding a Route in APIM
So in Part 4 we added an APIM layer which allows us to govern the AI and set up routes independent of what we specify for the function itself; this allows us to present a model of consistency for the API, even if under the hood the services are varied and support a variety of different route forms. Here we want to add a route in APIM for our GetAll operation.
Here are the steps for doing this (assuming this call is being added to an existing APIM):
- Access the APIM instance
- Select APIs and select Add Operation
- This will ask you to provide a route – remember route forwarding happens with each communique into the APIM
- Test the connection with Postman – remember if you followed the Products discussion in Part 5 you will have to provide the token
I mentioned route forwarding with point #3 and this is important to understand, its also discussed in Part 3. When APIM receives a matching route it calls the mapped call with the route part beyond the version:
Ex. http://www.somehost.com/api/v1/version -> /version is passed to mapped resource
You can override this behavior, as is discussed in Part 3. For this /version call, it is likely not necessary.
We know have a full fledged microservice that is focused on image processing and retrieval. Our next section will focus on why Serverless is a big deal for Microservices and other lessons learned in my experience
One thought on “Serverless Microservice: Reading our Data”