Use Cases for API Test Type
ThousandEyes users often care deeply about third-party or backend services as part of their digital supply chain. Many of these services are APIs.
A customer digital experience use case could be a mobile-application food delivery or rideshare service. The app might rely on a third-party mapping API for both address verification and auto-complete suggestions. If the mapping API goes down, the delivery service can’t take new requests, and it might lose revenue.
For network infrastructure, other ThousandEyes tests (network, BGP, and DNS) provide visibility on the current state of a network and information into specific common failure points in the overlay or underlay.
For application visibility, the API test can reveal application state and common application failure patterns. This information shows the relationship between the state of a user experience with conditions in backend application systems.
Examples of Web APIs
Here are a few more specific examples of third-party web APIs that you can test using the ThousandEyes API test type:
eCommerce apps that access APIs for various shipping companies to calculate shipping costs during checkout, or payment gateway APIs such as Stripe or Paypal.
Any “Find a Store Near You” function that relies on a third-party mapping API such as Google Maps.
Banks that rely on programmatic SMS APIs such as Twilio when texting fraud alerts to their customers.
Authentication APIs such as the familiar “Login with Facebook” used by many online apps and portals as an alternative to manual entry of user credentials.
Travel websites that aggregate data from airlines, hotels, and car rental services using each provider’s own API.
The above APIs are also revenue generators for their owners. A provider of the above APIs could also test their own API to ensure continuity of their revenue stream.
Testing Use Cases
Here are some examples how one might use the API test type, and for what purpose:
IT operations: Understand the state of key internal application APIs in order to pass along the scope and probable root cause of an issue to the team or vendor responsible for that particular feature.
Network: Identify loss along the network path so that if there is an outage in a key API due to network issues, it’s easier to find the probable root cause.
Applications: Understand the performance of all of the application APIs, in order to monitor application health
How is a particular 3rd Party API performing?
Examples include financial services, customer payment portals, Cisco’s vManage for SD-WAN, ThousandEyes’ own APIs. You can test multiple calls or endpoints within one specific API.
How are all my APIs doing?
You can create a ThousandEyes dashboard to see the up/down state of all APIs used or monitored by a particular team. You’d create a separate API test for each target domain, and then create a dashboard to consolidate information for all the APIs in one view.
What can we monitor about the API?
Performance: How quickly does the API return data or respond to requests?
Availability: Does the API respond when I ring the front doorbell?
Functionality: Does the API return the right information?
When to Use an API Test
The API test is a web layer test. While some of the other ThousandEyes web layer test types can also perform basic API endpoint testing, they can’t test as deeply as the API test.
An HTTP server test can test whether an HTTP Server is up, and should be used when you care mainly about the availability of the HTTP Server. It cannot provide detailed information on what is happening specifically for APIs.
For example, HTTP server tests:
Only allow GET and POST HTTP methods
Have limited capabilities for verifying the response is valid
Do not display response body contents
A transaction test can include API calls within the test script, but the primary focus is on browser emulation of a user experience. Unless you need to combine the browser synthetics with API calls, use the API test type instead. If you do use a transaction test, you can include markers where the API calls occur, in order to better identify each call within the browser session within the resulting test view.
However, a transaction test does not provide detailed network timings for API calls or show the API Response in views. A transaction test stops the test at any failure, while API tests will try all of the API calls in sequence, and show you the details of each where available.
An API test can look deeper within a single target domain and test various API calls, including passing values and parameters from one call to the next. It provides metrics specifically for measuring API performance and capabilities specifically for easier troubleshooting.
Using a Transaction Test vs an API Test
Prior to the introduction of the API test type, it was possible to create transaction tests consisting solely of API calls. So what’s the difference? The difference between a transaction test and an API test is that the transaction test uses Chromium to emulate user journeys, and the API test does not.
If you’re mainly interested in checking up on the health of API endpoints, use an API test type.
If you’re adding API calls interspersed with browser actions, use a transaction test.
Each step is a single API call, and the API test runs each step sequentially, once through. If you need to use looping or conditionals, use a transaction test.
Should I Convert my Existing Transaction Tests to API tests?
If you’re considering converting your existing all-API transaction tests into API tests, some reasons to convert include:
You’ll get more out of the API test view. Test views for a transaction test consisting solely of API calls are still useful, but they don’t have the same detailed request/response information that the new API test view offers.
The API test needs less of a timeout to run the same test. A transaction test spins up a browser and that takes time and resources.
Reasons you might still use a transaction test:
You’re testing SOAP/XML APIs
You need to employ complex logic or transformations between your API steps.
API Test and Other ThousandEyes Tests for Root Cause
Sometimes, the first failure signal isn’t the root cause. One example could be a widely used service like Google Maps. If that service experiences an outage, it’s likely other services using it will fail as well. If you’re testing any of those other services, it may not be obvious at first what the root cause is.
You can potentially speed up your mean time to resolution (MTTR) by correlating API degradation signals with other areas within ThousandEyes:
The ThousandEyes Internet Insights Outages map
The path visualization shown on the Network view layer in most ThousandEyes test views, comparing views for the API test itself with other related tests as well
API assertion failures within the API test itself, also shown on ThousandEyes test view for that test
If you want to go farther, you can:
Augment the API monitoring with more tests, either by adding more use cases (breadth) or by making your existing tests more sophisticated (depth).
Correlate API test failures with service health signals from other integrations that you may already have in place.
Last updated