This post is part of a series
If you have developed or consumed HTTP APIs or webhooks, chances are that you have had the need of troubleshooting and inspecting HTTP requests. In the past, there was a very popular and handy free site called Request Bin (requestb.in) that allowed you to capture your HTTP requests and inspect their content, including the body, headers, and query params, etc. Unfortunately, due to ongoing abuse, the publicly hosted version of Request Bin was discontinued. After that, other sites started offering hosted alternatives to Request Bin. You also have the possibility of self-hosting and running your own Request Bin in a container.
One concern I have always had when using this type of free public site to inspect my HTTP requests is that I do not know how they handle my information. More often than not, I need to inspect requests that contain credentials, JWTs with access to sensitive resources and payloads with sensitive information. I cannot be sure that the provider is not logging those requests. Furthermore, it is not possible to guarantee that other external users will not get or guess my request bin identifier, which would give them full access to my HTTP request history.
Most of my development these days happens on Azure. Thus, the easiest option to solve this problem would be to host my own Request Bin on Azure Container Instances. However, this is not very cost-effective, as I would need to pay for the container instance even if it is idle for long periods, or dealing with the overhead of deleting it every time I finish inspecting HTTP request and redeploying when needed again. Being a developer, I started wondering how hard it could be to build my own Request Bin and host it on Azure Functions so that I would not need to pay when it was idle.
I wanted to try out first implementing it using Azure Functions with a memory cache that could be used across multiple requests (with the corresponding limitations). In this post (Part 1), I explain how I built a Serverless Request Bin using Azure Functions and a memory cache and how you can easily deploy your own so you can use it for your development tasks to inspect HTTP Requests in a secure and cost-effective manner.
In a future post, I'll explore how to do it using the new features of Durable Entities of Azure Durable Functions.
The solution’s code is available on GitHub. Please don’t expect an enterprise-grade solution. Consider this a sample solution for personal use. When I was building it, I wanted to try out the new Dependency Injection capabilities of Azure Functions, and the ability to return not only an ObjectResult
but HTML content from functions. I also used a DotLiquid template to transform objects to HTML.
The Azure Function App is composed of four functions. Functions are just wrappers that call services. Services are instantiated via Constructor Dependency Injection and configured during the FunctionStartup
. The functions are described as follows:
If you deploy your own instance of the Serverless Request Bin, you would get some benefits, including:
Deploying your own instance on your Azure Subscription is very easy. You just need to click on the button below, and this will take you to a page similar to the one shown after.
If you are planning to deploy the Serverless Request Bin in a new resource group, it is highly recommended creating the resource group in advance, so you can choose the region for the resource group. At the time of writing, the deploy button option does not allow you to choose the region for a new resource group.
Please read the following section to understand the purpose of each of the settings.
The configuration options and settings of the Serverless Request Bin are described in the table below. Some of these options are available only at deployment time, while others are also available after deployment as Application Settings of the Function App created.
Setting |
Description |
Can be updated after deployment? |
Directory |
Azure Active Directory Tenant that you want to use to deploy the solution |
No |
Subscription |
Azure subscription in which you want to deploy the solution |
No |
App Name |
Used to name the different components of the Serverless Request Bin, including the Function App, the consumption plan, Application Insights, and the Azure Storage account. |
No |
App Insights Region |
Given that Application Insights is not available in all regions, choose the closest region to the resource group. |
No |
Request Bin Provider |
App Setting to configure the Request Bin Provider to store the HTTP request history. Currently, only |
Yes |
Request Bin Renderer |
App Setting to configure the Request Bin Renderer to return the Request Bin history to the user. Currently, only |
Yes |
Request Bin Renderer Template |
File name of the Liquid template to use while rendering the request bin history. Currently, only the |
Yes |
Request Bin Max Size |
Maximum number of request to store in the Request Bin. |
Yes |
Request Body Max Length |
Maximum number of characters to read and store of a request body. If a request body is larger than this limit, the body would be truncated. |
Yes |
Request Bin Sliding Expiration |
For the |
Yes |
Request Bin Absolute Expiration |
For the |
Yes |
Using the Serverless Request Bin is very easy. Once you have successfully deployed the Serverless Request Bin, you can use it as follows:
https://<yourfunctionapp>.azurewebsites.net/<binId>
POST https://<yourfunctionapp>.azurewebsites.net/1234567890?a=1&b=2
GET https://<yourfunctionapp>.azurewebsites.net/history/<binId>
GET https://<yourfunctionapp>.azurewebsites.net/history/1234567890
DELETE
https://<yourfunctionapp>.azurewebsites.net/history/<binId>
DELETE
https://<yourfunctionapp>.azurewebsites.net/history/1234567890
You can just use the solution and hopefully, it provides the value you want from it. However, you can also learn some things from the source code, including:
IOptions<T>
interface via Dependency Injection.ObjectResult
. However, you can also return a ContentResult
, in this case, we are returning content of type text/html
.This solution should be considered a sample application and only targeted to personal use. There are some known limitations as listed below:
Being this a sample solution, there is a lot of room for improvement. The most important one being Durability. It is on my plans to write a second version of the Serverless Request Bin using Durable Entities. Additionally, you might be thinking that it would be much better to have a lightweight Single Page Application that renders in a more elegant way the Request Bin history to the user. I agree, and contributions are more than welcome :)
In this post and the companion sample code, I’ve shown how I built a Serverless Request Bin using Azure Functions and how you can deploy and configure your own. Feel free to use it for your own development tasks. I hope you find it helpful either as a solution or as a sample. Please provide feedback by raising issues or even contribute by submitting your pull requests on GitHub!
Happy coding!
Cross-posted on Paco’s Blog
Follow Paco on @pacodelacruz