Supporting web APIs can open a labyrinth of issues you need to proactively manage. It can be tricky finding easy ways to get notified about problems before your customers encounter errors. Plus, time is always of the essence, and infrastructure to capture errors isn’t always readily available. Fortunately, Runscope has a quick and easy way to log your HTTP error data for greater visibility so you can fix problems fast, in just a few steps.
Logging failed HTTP requests and responses provides a complete picture of the failed interaction. HTTP requests are designed to be stateless and self-descriptive, so everything you need to know about the intent of the client is captured in the request. There is no other transient context that gets lost. So tracking down the source of an error is much easier than when dealing with complex stateful interactions. Below, we take you through the steps to integrating with the Runscope API to log this data in your Runscope instance.
Integrating with the Runscope API
By using the Runscope API and a small piece of middleware in your Web API, you can push failed requests into a Runscope bucket. Logging in to the Runscope Dashboard allows you to see the failed requests. To close the loop, use Runscope’s notification integrations with services like Slack and PagerDuty to notify you when an error occurs, and create some API tests to check if new errors appeared.
Creating new requests via the Runscope API is fairly straightforward and most web platforms have infrastructure for inserting middleware into the request response pipeline. In Python there is WSGI, Ruby has Rack, Node.js has Express Middleware.
If you happen to be in the .Net space, life is even easier because I have already built the middleware component to do the hard work. Simply install the nuget package, and then add the following code to your API configuration.
You can create a new API Key by following the instructions in this screencast. The Bucket Key appears in the bottom left corner of the dashboard on the Runscope Traffic Inspector page.
The third parameter is a filter function that determines which bucket to use to record the request and response. Returning a null bucket indicates that we don’t want to store the request. This example simply stores all 4XX or 5XX into a bucket. However, that function can be as clever as you like. The source for this project is available on Github.
An interesting benefit of this approach to error logging is that if you have multiple HTTP APIs, either internal or external, you can configure each API to post errors to the same Runscope bucket. If you get into a situation where there are cascading failures of requests between APIs then you can easily see which API failed first and the impact of that failure.
It’s easy to log HTTP errors with Runscope, and even easier to get started. Sign up for free today.