Posts filtered by category: debugging
Debugging and troubleshooting APIs is something that any developer that works with APIs has to go through at some point. In an ideal world, APIs would always return a 200 OK with just the right data that we need, or in case of a failure, it would return us the perfect status code and error message allowing us to easily understand what went wrong.
In reality, APIs don't always work like that. API developers might have constraints that do not allow them to implement the most informative status code or error message, API errors can be triggered by real-world conditions that are hard to account or test for, and sometimes ourselves, as API users, can make requests with typos or mistakes that APIs just don't know how to handle.
In this post, we're going to focus on API users and what they can do to debug common API errors they might encounter when testing and working with APIs, whether these APIs are public or private […]
Read More →
Trustpilot is a review platform where people can read, write, and share reviews for all kinds of businesses. They have also been Runscope users since 2015, and we have featured them in other blog posts, such as how they monitor over 600 microservices.
One of the most important parts of API monitoring is getting notified when something breaks. Trustpilot uses Slack as their main communication hub, and so they rely on notifications that are sent from Runscope to Slack in case something breaks.
The default Runscope-Slack integration was enough for the Trustpilot team for a while. They made sure to use the threshold feature to only receive notifications after a test failed 3 times in a row, and again when the test returns passing, to control the overall number of notifications they would get.
But as their architecture evolved, and their Runscope usage grew, the amount of notifications grew as well. Add those up with other 3rd-party services, and they really started to build up. And getting too many alerts can be just as bad as getting zero alerts. The team started suffering from notification fatigue […]
Read More →
APIs. You depend on them, but can you always trust them to work as advertised? The truth is that APIs can fail, and even when they don't fail, they can perform in ways that are less than adequate. When that happens, your application may be left hanging, or worse yet, it may crash. What kind of failures are we talking about, and what can you do about them?
First, though, consider what an API does—It provides a way for a programmer to communicate with an external application or service, and to ask that application to do something. You may or may not know what the other program does internally with your data and your request, but as long as everything works correctly, all you need to know is how to use the API. But that is not enough to ensure that APIs perform adequately.
In this article, we'll look at three common reasons why an API might fail or underperform, and how DevOps engineers can address them. [...]
Read More →
This is a guest post by Bruce Wang and Glen Semino from SYNQ, a video API built for developers. In this post, they explain the tools and processes they use to keep the company's API operations running smoothly, and share a real-world story of how they found an API bug before launching a new feature.
There are a lot of tools out there, and sometimes its hard to sift through them all. Here’s a simple guide to combine 3 tools, Runscope, PagerDuty and StatusPage to create a powerful cloud operational workflow that will give you peace of mind and clear visibility to your application for your customers and internal teams alike!
In case you’re not familiar with the tools, here’s a quick rundown:
- Runscope — highly flexible API testing and monitoring service
- PagerDuty — incident management system
- StatusPage — Customer-facing API health status page
It’s important to implement tools for specific purposes, and we wanted to integrate these 3 tools to help manage our operational process better. In the following examples, we’re going to show you how...
Read More →
We frequently run into users who are looking to run an API test multiple times, using a variety of initial variables. For example, the user might be looking to:
- Test the same request against a list of user ids, where user_id is the only query string parameter that changes.
- Test edge cases for an API call. Passing a string to an endpoint that expects an int, or passing special characters to it, and making sure that nothing breaks.
Share tests and results for multiple variable sets with other teammates for debugging.
We have been able to accommodate this feature for a long time using our Batch Trigger URLs. With a GET request to a Batch Trigger URL, you can pass in an array of objects to specify initial variables for the test, and kick off up to 50 test runs at one time using different sets of variables.
But what if you want an easier way to do this than to try to format an API request with a bunch of variables and build a JSON array with the different sets? And how do you match up your responses easily to the different sets of variables? What if we could make this easier?
Read More →
Have you ever used an API that returned an HTML error page instead of the JSON you expected, causing your code to blow up? What about receiving a 200 OK status code with a cryptic error message in your response?
Building an API can be as quick as serving fast food. Frameworks like Express, Flask, and Sinatra combined with Heroku or zeit's now help any developer have an API up and running in a few minutes.
However, building a truly secure, sturdy, hearty API, can take a little more work, just as a chef takes more time when crafting a great meal. You need great docs, clear and concise error messages, and to meet developers' expectations of...
Read More →