Benchmarking Web API Quality - Revisited

03/18/2019 ∙ by David Bermbach, et al. ∙ ibm Berlin Institute of Technology (Technische Universität Berlin) 0

Modern applications increasingly interact with web APIs - reusable components, deployed and operated outside the application, and accessed over the network. Their existence, arguably, spurs application innovations, making it easy to integrate data or functionalities. While previous work has analyzed the ecosystem of web APIs and their design, little is known about web API quality at runtime. This gap is critical, as qualities including availability, latency, or security can severely impact applications and user experience. In this paper, we revisit a 3-month, geo-distributed benchmark of popular web APIs, originally performed in 2015. We repeat this benchmark in 2018 and compare results from these two benchmarks regarding availability and latency. We furthermore introduce new results from assessing web API security measurements, collected both in 2015 and 2018, and results from our attempts to reach out to API providers with the results from our 2015 experiments. Our extensive experiments show that web API qualities vary 1.) based on the geo-distribution of clients, 2.) during our individual experiments, and 3.) between the two experiments. Our findings provide evidence to foster the discussion around web API quality, and can act as a basis for the creation of tools and approaches to mitigate quality issues.



There are no comments yet.


page 8

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

©2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.

Today, mobile, web, or even desktop applications regularly rely on third-party data or functionalities, which they consume through web Application Programming Interfaces (web APIs). Web APIs provide these applications with otherwise inaccessible resources such as access to global social networks (e.g., web APIs provided by Twitter, Facebook, or LinkedIn), advanced machine-learning capabilities (e.g., web APIs provided by IBM Watson or Google Cloud AI), or complex transaction processing (e.g., web APIs by Stripe or PayPal for payment processing or the Flight Booking API). Today, application developers can build on…

  • [leftmargin=1em]

  • ubiquitous technologies, for example the Hypertext Transfer Protocol (HTTP) or Asynchronous JavaScript and XML (AJAX),

  • architectural styles, for example the Representational State Transfer (REST) [1],

  • de-facto standards for describing web APIs, for example the OpenAPI Specification111,

  • research results, for example from service-oriented computing, cloud computing, or mash-ups, and finally

  • a myriad of web API client libraries in any established programming language,

so that integrating web APIs with an application no longer poses a technological challenge. Therefore, we now see thousands of public APIs as well as applications using them [2].

In consequence, though, application developers now heavily rely on third-party entities beyond their control sphere for core functionality of their applications. This can have impacts on applications’ user experience. For example, erroneous integration of core application capabilities, e.g., a payment service, via APIs can impede end user experience [3]. High request latency can lead to slow application response times, which have been found to disrupt users’ flow of thought or eventually cause loss of attention [4]. A long-term experiment performed by Google showed that increasing response times artificially from 100ms to 400ms did measurably decrease the average amount of searches performed by users [5]. User experience and, hence, application reputation is thus directly affected by actions and non-actions of the API providers. As another example, APIs may be discontinued or changed without notice, thus disabling applications. Previous work found that mobile applications silently fail and, in cases, even crash when confronted with mutated (e.g., adapted or faulty) web API responses [6]. In sum, web API endpoints222We denote an endpoint to be the combination of a resource, identified by a URL, and an HTTP method as proposed in [7]. often present themselves as black-boxes with volatile qualities – i.e., availability, latency, security, or usage limitations – to consumers.

Based on this observation, in 2016, we published a study on web API quality [8], where we described our findings from an experiment of benchmarking 15 endpoints of diverse web APIs for three months from geo-distributed clients. Core results were that availability and latency highly depend on the geo-origin of requests as well as the protocol used (HTTP vs. HTTPS). For this paper, we extend, repeat, and correct our previous study333Where applicable, this paper reuses parts of the text material and figures from our previous publication [8].. Namely, we repeated all experiments in 2018, reanalyze old and new availability and latency measurements, analyze yet unpublished measurements on provider security preferences, and present the results of trying to contact the providers of all benchmarked APIs with the goal of (i) finding explanations for the observations from our 2016 paper and (ii) to assess availability and quality of customer service. We thus make the following contributions:

  1. We extend our previous measurement method to also collect information on Transport Layer Security (TLS) cipher suite preferences of providers.

  2. We report findings on how TLS cipher suite preferences of providers evolved over time in both our 2015 and 2018 measurements.

  3. We report detailed findings from analyzing and comparing our 2015 and 2018 latency and availability measurements.

  4. We discuss the results of reaching out to the providers of all benchmarked APIs about our original findings from 2015.

This paper is structured as follows: we present background on web APIs, possible failures when consuming them, and web API qualities in Section 2. We present the implementation of our benchmarking client and the design of our experiments – both with regard to benchmarked API endpoints and experiment setup – in Section 3. In the following sections, we compare findings from the 2015 and 2018 experiments, addressing availability in Section 4, latency in Section 5, and security in Section 6. We present findings from reaching out to API providers with our 2015 results in Section 7. We discuss this work’s threats to validity and implications for application developers in Section 8. After presenting related work in Section 9, we conclude in Section 10.

2 Background

In this section, we give an overview of selected qualities in web APIs and discuss how they can be measured. For this purpose, we start with a description of individual steps in performing web API requests (Section 2.1) and potential root causes of failures (Section 2.2). Afterwards, we characterize the qualities which we have studied for this paper (Section 2.3).

2.1 Interaction with Web APIs

Web APIs expose data, e.g., a user profile or an image file, and functionalities, e.g., a payment process or the management of a virtual machine through a resource abstraction. This abstraction enables users to manipulate these resources without requiring insight into the underlying implementation.

Developers can access Web APIs through the Hypertext Transfer Protocol (HTTP), which again uses the Transmission Control Protocol (TCP) for error-free, complete, and ordered data transmission on the transport layer, and the Internet Protocol (IP) at the network layer. Figure 1 illustrates the steps involved in a typical HTTP request444For simplicity’s sake, we do not include possible complications like proxies, keep alive connections, caches, or gateways in this Figure..

Fig. 1: Overview of the Steps Involved in Sending an HTTP Request

The resources exposed by an API are identified by unified resource locators (URLs), describing the scheme to be used for interaction, the server Internet address, and the specific resource identifier. The semantics of interactions with a resource depend upon the HTTP method, e.g., GET, POST, or DELETE. Before a client can send a request to the server that offers the web API, client and server need to establish a TCP connection. For this purpose, the client first sends a lookup request for the URL of the server to a Domain Name Service (DNS) server which returns the IP address and port number of the target host. If available, IP address and port may be returned from a local cache (step 1); otherwise, an external DNS authority is consulted (step 2). Afterwards, the client opens a socket connection to the server, i.e., it initiates TCP’s three-way handshake, thus, establishing a TCP connection (step 3). Based on this connection, multiple HTTP requests with application data can be sent to the server.

If additional security is required, the client will typically use HTTPS which introduces the Transport Layer Security (TLS) protocol555TLS has largely replaced its predecessor SSL which is typically supported only for compatibility with old clients. between HTTP and TCP/IP. TLS has two main phases: a negotiation phase and a bulk data transfer phase. In the negotiation phase, the server authenticates itself through its X.509 certificate. Afterwards, the client sends its list of supported cipher suites (a combination of symmetric encryption algorithm and a message authentication code (MAC)) to the server which then selects a cipher suite supported by both client and server and responds accordingly. Using asymmetric encryption (e.g., RSA) and key exchange protocols (e.g., DHE), client and server also agree on a symmetric key and other TLS sessions parameters.

After this TLS handshake has been completed, the server signals a change to the bulk data transfer phase. During that phase, each HTTP request is broken down into data packets which are – based on the agreed session parameters – encrypted and signed before transmission over the network. Cipher suite and protocol version determine whether encrypt-then-MAC or the reverse order is used. The recipient can then reassemble the original request and verify its integrity based on the received MAC.

2.2 Sources of Failures

Considering the typical HTTP request flow described in section 2.1, a number of possible breakpoints emerge at which a request may fail. As we will see, while some of these are in control of a web API provider, others are not.

A failed DNS lookup is caused by attempting to look up a host for which no DNS entry exists or by a network partitioning which causes the lookup request to an authoritative DNS server to time out. The first error source is rather unlikely for web API requests with the correct URL, as it would either imply the disappearance of the API’s host altogether or indicate problems in the DNS system itself. Typically, a failed lookup results in a timeout error reported to the client. The second error source appears only in case that the network is not available and the DNS entry is not yet cached locally.

A client connection error appears if no TCP connection can be established between the client and the server hosting the web API. Reasons for this error are network partitioning or that the server is in a state where it cannot accept connections (for example, because it crashed).

In the case of HTTPS, a request can also fail if authentication of the server is not possible due to certificate issues or if there is no cipher suite supported by both client and server.

A client error appears if the request sent by the client cannot be processed by the server. One reason for client errors is that the requested resource cannot be found on the server. Furthermore, users may not be authorized to access the requested resource. The client may not have been aware of authentication mechanism like basic authentication or OAuth or may not own proper credentials. Furthermore, providers may deny authorization for specific clients if their usage of an API exceeds certain thresholds. A broad range of client errors are considered by HTTP and should result in the server sending 4xx status codes. While these errors are attested to the client, it is important to note that their appearance can be tightly related to actions of the web API provider. For example, many changes on the server, e.g., introducing authentication, removing or renaming resources, or changing request formatting, cause existing clients to malfunction, i.e., the client error is in fact caused by the web API provider.

A server error appears if the server fails to process an otherwise correct request. Reasons for server errors may include failed lookups for resources in databases or errors in the execution of functionalities. Server errors are, similar to client errors, considered by HTTP and should result in the server sending 5xx status codes.

2.3 Qualities

Systems have a number of properties. These can be functional, i.e., describe the abilities of said system, or non-functional, i.e., describe the quality of said system. Quality describes how “good” or “bad” a system fulfills its tasks along several dimensions666It depends on the respective quality what “good” or “bad” implies. – the qualities [9].

There is a plethora of qualities that we can see in web APIs. Examples range from availability and performance, to security, reliability, scalability, cost, or correctness (of results). All these qualities are inherently connected through complex direct and indirect tradeoff relationships [10]. In this paper, we focus on three qualities: availability, performance, and (transport layer) security.

2.3.1 Availability

Generally, availability describes the likelihood of a system – here, a web API – being able to respond to requests. Providing a concise definition of availability, though, is non-trivial: Does an API have to send correct responses or does it suffice if it is still able to tell about current problems? For this paper, we distinguish three different kinds of availability to consider these questions:

Pingability describes whether there is anything “alive” at the API provider’s site. This may be a load balancer or even a fault endpoint. For a single machine deployment, pingability describes whether said machine is reachable at an operating system level. Pingability is fulfilled if, at the web API’s URL, some entity responds to basic low level requests, e.g., ping requests (using the ICMP protocol).

Accessibility describes whether the resource represented by the web API is still accessible but not necessarily able to fulfill its task. For a single machine deployment, accessibility describes whether the web server component is reachable but does not require the hosted application logic to be accessible. A web API is accessible if it responds to HTTP requests using one of the predefined HTTP status codes.

Successability describes whether the web API is fully functional. For a single host deployment, it requires the application logic to be working777Please, note, that successability does not say anything about correctness of results.. Hence, we define successability to be fulfilled if a web API responds to requests using 2xx or 3xx status codes.

2.3.2 Performance

Performance has two dimensions: latency and throughput. Latency describes the amount of time between the start of a request at the client and the end of receiving a response, also at the client. Throughput, on the other hand, describes the number of requests a web API is handling at a given point in time. Typically, throughput measurements try to determine the maximum throughput, i.e., the maximum number of requests that a web API is able to handle without timeouts.

Usually, these two dimensions are interconnected: If the load increases towards maximum throughput, then latency will increase. If this is not the case, then the system behind the web API is typically referred to as elastically scalable [11, 12].

2.3.3 Security

Security is typically characterized along several dimensions – here, we will focus on the two arguably most relevant for TLS: confidentiality and integrity. Basically, confidentiality describes whether unauthorized entities are able to access the content of API requests, and integrity asserts that transmitted data packets cannot be manipulated without the manipulation being noticed.

It is hard to quantify how secure a web API interaction is with regards to confidentiality and integrity as this would require knowledge on all possible attack vectors. However, it is possible to interpret the selected

cipher suites of actual API requests and the general preference order of the API provider and distinguish between weaker and stronger cipher suites.

Cipher suites list cryptographic algorithms for use in TLS (and previously SSL). A cipher suite generally names the algorithms to use for 1) key exchange, 2) authentication, 3) bulk encryption (this algorithm is also called the “cipher”), and 4) message authentication code (MAC; which is used to ensure the integrity of a message). Servers typically support a ranked list of cipher suites, from which one suite to use is agreed-on with the client during the TLS handshake procedure.

To reason about the security of different cipher suites, we device the following heuristic

cipher suite security score per cipher suite:

where is if modern algorithms are used, if no perfect forward secrecy is guaranteed, and if a generally known-to-be-weak algorithm (e.g., RC4, DES) is used. The is if the selected cipher has a strength of at least 256 bit. The idea of these scores is not to make absolute statements about the security provided by a suite, but rather to be able to compare servers supporting different sets of cipher suites. For that purpose, based on individual cipher suite security scores, we devise the server security score of a server to be:

where is the ranked list of cipher suites supported by the server (i.e., the ordered list of server preferences), is the cipher suite security score of a suite , and is the rank of the same suite . In other words, the server security score is higher when modern cipher suites are near the top of the ranked list and lower when weak cipher suites are included, especially near the top.

As a toy example, consider a server whose cipher suite preference list is 1.) ECDHE-RSA-AES256-SHA384, 2.) ECDHE-ECDSA-AES128-SHA, and 3. RC4-SHA), which have cipher suite security scores, respectively, of , , and . The resulting server security score would be .

3 Experiment Design

In this section, we give an overview of our experiment setup. We start with the implementation of the benchmarking client (Section 3.1), followed by a description of chosen API endpoints (Section 3.2) before continuing with the parameters of our experiment setup (Section 3.3).

3.1 Benchmark Implementation

We have built our measurement system around the quality definitions described in Section 2.3: Pingability can be measured by sending a ping request to the respective endpoint using the standard Linux ping implementation; accessibility and successability can be measured by sending HTTP or HTTPS requests. This also allows us to track request latencies. Originally, we also planned to measure throughput (and, thus, also scalability since we do not have any insight into the API provider’s implementation) by sending large numbers of concurrent requests. For our experiments, we refrained from doing so since most provider’s terms of service explicitly rule out any kind of usage which would resemble a DDoS attack. Therefore, we also recommend strongly that application developers who plan to roll out their application to large user groups should contact the API providers about throughput limits – no matter whether they are using a free or a paid/rate-limited API. Our HTTP/HTTPS client is implemented in Java, using the basic HttpURLConnection class.

For security measurements, we obtain the list of cipher suites offered by API servers for HTTPS requests. Since, in our scenario, the API endpoint decides on the cipher suite which then offers different levels of confidentiality and integrity, we also propose to measure the preference order of the API provider, i.e., does the provider prioritize fast but less secure cipher suites or not. For this, we use the open source project cipherscan888

Our measurement toolkit is parameterized with a list of API endpoints. Based on this parameter list, it periodically sends ping, HTTP, and HTTPS requests. The toolkit then logs detailed results which are analyzed when the benchmark run has been completed. Our open source prototype for benchmarking web APIs is publicly available999

In an initial test run before the 2018 experiment, we noticed that the Java VM running our toolkit crashed or the virtual machine was restarted by Amazon. This forced us to restart the experiment. To be able to detect such crashes very fast, we extended our original toolkit with an embedded HTTP server to expose an endpoint which returns the latest measurement results for all APIs and protocols as a single page HTML site upon GET requests. We could then use the commercial Uptime Robot service101010See to monitor this endpoint and inform us about tool crashes so that we could if necessary restart the respective machine as soon as possible. We had no incidence reported by Uptime Robot during our 2018 data collection. More details about the potential threat to validity of dying benchmarking clients are presented in Sections 8.1 and 8.2.

API Name ICMP/HTTP/HTTPS Request Meaning
Apple iTunes X / X / X Get links to resources on artists
Amazon S3 - / X / X Get file list for the 1000 genomes public data set
BBC - / X / - Get the playlist for BBC Radio 1
Consumer Finance X / X / X Retrieve data on consumer complaints on financial products in the US
Flickr X / X / X Get list of recent photo and video uploads
Google Books X / - / X Get book metadata by ISBN
Google Maps X / X / X Query location information by address
MusicBrainz X / X / X Retrieve information about artists and their music
OpenWeather Map X / X / - Get weather data by address X / X / X Get location information based on UK zip codes - / X / X Retrieve street level crime data from the UK
Spotify X / X / X Get information on a given artist
Twitter X / X / - Get the number of mentions for a given URL
Wikipedia X / X / X Retrieve a Wikipedia article
Yahoo X / X / X Get weather data by address
TABLE I: Benchmarked API Endpoints and Supported Protocols in 2015 [8].

3.2 Analyzed Web API Endpoints

Typically, web API endpoints require clients to authenticate to interact with the resources they expose. Authentication mechanisms include basic authentication, where a username and password or a token have to be sent with every request, or the more frequently used OAuth. OAuth allows clients to access web APIs without having to expose users’ credentials. OAuth, however, requires eventual human interaction to authorize client applications for requests and involves additional requests to establish authentication. While this is feasible for actual applications, it is prohibitive for benchmarking purposes. One way to circumvent the need for human interaction is to “automate” it through the use of people services [13], but latency and availability measurements would then become entirely meaningless. Another possibility is to make requests using API-specific software development kits (SDKs), which hide such complexities from the client. However, SDKs are not readily available for all APIs. Furthermore, correctly interpreting benchmark results obtained using SDKs would require us to fully understand their inner workings (e.g., through code-reviews) and eventually to align them for comparability. All in all, we thus decided to perform our experiments with unauthenticated API endpoints only. Focusing on these endpoints allows us to control the parameters influencing our measurements, e.g., as we avoid multiple roundtrips (possibly to third-party entities) for authentication.

Already for our original paper, we identified unauthenticated API endpoints ( accessible via HTTP or HTTPS, accessible only via HTTP, and one accessible only via HTTPS) from a variety of different providers with regards to company sizes, country of origin, local or global target users, public or private sector. We specifically included some of the most well-known providers like Google, Apple, Amazon, and Twitter. Table I gives an overview of the web API endpoints which we originally selected for our experiments in 2015, and of the protocols they supported.

Already during our 2015 experiments, two endpoints became permanently unavailable [8]. Since then there have been additional changes as some resources, their endpoints, or even whole APIs that we originally targeted were no longer accessible in 2018. Table II indicates all changes to the HTTP and HTTPS endpoints for the anonymized APIs. Notably, some HTTP endpoints available in 2015 seem to have been deprecated since. In one case, for API 4, the originally targeted resource seized to exist, and we had to replace it (with an, unfortunately, much smaller one). Table II also indicates changes in response size between 2015 and 2018. Response sizes evolved significantly, even for cases where the API, endpoint, or even targeted resource remained constant. For some APIs, we cannot report response size changes as we were no longer able to complete requests, whether with HTTP or HTTPS.

API HTTP change HTTPS change Resp. size
1 - - -3.1%
2 no longer available - n.a.
3 - - +12.48%
4 new resource new resource -99.92%
5 - - +254.56%
6 - - -13.52%
7 - - +25.57%
8 - - -45.68%
9 - - +42.85%
10 - - +16.03%
11 - - +50.03%
12 no longer available - n.a.
13 no longer available no longer available n.a.
14 no longer available - n.a.
15 no longer available - +38.53%
TABLE II: Changes in API Endpoints between 2015 and 2018

Please, note: In this work, we want to highlight unexpected behavior and unpredictability of web API quality but we do not aim to discredit individual API providers. For this reason, we decided to anonymize our results and will, for the remainder of this paper, only refer to these API endpoints as API-1 to API-15. There is no correlation between the identifiers and the order of API endpoints in Table I but we use the same mapping as in our 2016 paper [8]. However, we will reveal this mapping information upon request if we are convinced that the information will not be used to discredit individual providers.

3.3 Experiment Setup

To analyze whether web API quality varies depending on the geo-origin of the request, we deployed our toolkit in several locations. For this purpose, we used one Amazon EC2 instance in each of the following Amazon Web Services (AWS) regions: US East (Virginia), US West (Oregon), EU (Ireland), Asia (Singapore), Asia (Sydney), Asia (Tokyo), and South America (Sao Paulo).

We configured our toolkit to send ping, HTTP, and HTTPS requests every 5 minutes, but each starting at a different timestamp for the first request to avoid interference. Ping was configured to use 5 packets per request and we disabled local caching for HTTP and HTTPS requests. Our toolkit also triggered a full cipherscan run for each API endpoint every 12 hours.

Our first test started on August 20th, 2015 and our second test was started on January 30th, 2018. Both were kept running for exactly three months and used the identical deployment and configuration. Afterwards, the analysis of the vast result set took us almost a year111111The data collected in our experiments is available at

3.4 Reaching Out to Providers

Following our original paper, we contacted the providers of all analyzed web APIs with the goal of (i) finding explanations for the observed results, (ii) providing feedback to the providers, and (iii) to explore how easy it is to reach the providers, i.e., how easy it is for application developers to get help. For this purpose, we tried to find contact details for all providers using Google search but also via contacts of contacts on LinkedIn. To each contact we found, we tried to send the same text including our original paper and deviated only where necessary due to the respective communication channel (e.g., on Twitter). We describe the results of this reaching out process – including both observations on contact methods but also on outcomes of attempted contact – in section 7.

4 Availability Findings

In this section, we give an overview of our findings regarding availability of web APIs. Reported results are based on our experiments from both 2015 and 2018.

Finding #1: Pingability. Overall, all APIs show a very high pingability of around 99% in both 2015 and 2018. However, all APIs have very different pingability when comparing regions. This effect is particularly pronounced in the 2018 measurements for API-6: During the first month of our measurements, daily pingability went down to about 85% for three out of seven regions while the remaining regions still had 99% pingability. Figure 2 shows the geographical distribution of these regions. Beyond API-6, this was observable for all other APIs as well though less extreme as for these APIs only the number of nines varied. Table III

shows the distribution of lost ping packages across regions; overall, clients in South America appear to have a higher probability for pingability problems than elsewhere. Noticeably, API-6 which had the strongest variance and problems encountered their worst problem in Oregon and had very good pingability in Sao Paulo. All this, however, should be taken with a grain of salt as our experiment sent close to one million ping packages per API in total.

Fig. 2: Pingability of API-6 in February 2018 by Region
API Best Worst Avg Worst Region
API-1 6 211 66 Sao Paulo
API-3 4 374 82 Sao Paulo
API-4 7 74 32 Oregon
API-6 17 5852 2893 Oregon
API-7 6 235 71 Virginia
API-8 1 42 13 Sao Paulo
API-9 20 476 155 Sao Paulo
API-10 0 175 73 Sao Paulo
API-15 0 31 13 Sao Paulo
TABLE III: Distribution of Lost Ping Packages Across Regions

Finding #2: Pingability vs. Availability. In our experiments, we also found that pingability is usually a good proxy for API availability. This, however, is not always the case. Figure 3 shows the pingability and accessibility of API-6 in our 2018 benchmark. As can be seen in the left part, API-6 had severe pingability problems which were not related to the overall availability of the HTTP(S) endpoints. In this period of time, using pingability as a proxy for accessibility would severely underestimate the API accessibility. In contrast, the right half of the chart shows the expected correlation of pingability and accessibility.

Fig. 3: Comparison of Daily Pingability and Accessibility of API-6 in 2018

Finding #3: HTTP Status Codes. Based on semantics of the HTTP protocol, applications are led to believe that they can expect 4xx HTTP status codes when they have done something wrong and 5xx when the fault lies with the server, or a response (2xx or 3xx) otherwise. This could not be further from the truth. Across all our experiments, we found that up to nearly 90% of all unavailabilities resulted in no response at all, i.e., a timeout or a loss of connection. See table IV which shows how frequently client-observable outcomes were a 4xx/5xx status code or some other sort of failure. Note, that during our 2015 benchmark, we saw two endpoints permanently going offline (the providers still exist at the time of writing this paper but deprecated the respective API endpoints): One permanently switched from 2xx to 4xx codes, the other did this for 48 hours only. Afterwards, requests failed without returning any status codes. In table IV, we show the full 2015 datasets as well as the dataset without these two APIs as both together account for about 94% of all failed requests in 2015. Overall, we can only recommend not to rely on the idea of receiving valid HTTP status codes.

Dataset Protocol 4XX 5XX None
2015 (all) HTTP 43% 5% 53%
HTTPS 3% 8% 89%
2015 (w/o HTTP 0% 74% 26%
offline endpoints) HTTPS 0% 89% 11%
2018 HTTP 0% 87% 13%
HTTPS 0% 80% 20%
TABLE IV: Distribution of Client-Observable Results (HTTP Status Code or None) for Failed Requests

Finding #4: Longevity of API Endpoints. As already described in finding #3, we saw two endpoints going offline during our 2015 experiments. Beyond this, four out of fourteen HTTP endpoints and one out of twelve HTTPS endpoints from our original paper were no longer available when we started our 2018 experiments (cf. Table II). At the time of writing this paper in March 2019, another three endpoints appear to be unavailable (either permanently or temporarily). All this together indicates that application developers should not necessarily rely on the longevity of the API endpoints used. Instead, they should closely monitor announcements on the provider’s websites and have contingency plans for using alternative API endpoints.

Finding #5: Correlation of Unavailability Across Regions and Protocols. Based on our detailed result logs, we also wanted to explore to which degree requests to the same API endpoint experience the same availability behavior when sent (i) from different geographical regions or (ii) via different protocols (HTTP vs. HTTPS). For this analysis, we synchronized the detailed results logs as much as possible – requests did not start at the exact same time due to clock differences on the measurement machines but also due to shifting request start timestamps (we sadly implemented our toolkit not using a precise scheduler but rather relied on Java’s Thread.sleep() method). This means that the following results should be taken with a grain of salt as they might underestimate the correlation. The results, however, still indicate that the effect could be leveraged for some of the requests. In future work, we plan to explore to which degree this is possible in practice.

How to read the results presented in Table V: The Table reports all aggregated results for different datasets (first column, for 2015 again with and without the two APIs that went completely offline) and strategies. For the strategies, REGION_CHANGE succeeds when one is able to successfully send a request from at least one other region once an API is not available from a specific region. HTTP_2_HTTPS and HTTPS_2_HTTP succeed when one is able to successfully send a request via the respective other protocol from the same machine once the first request failed. For each API, we calculated for which percentage of the failed requests the respective strategy would have been successful. The numbers in the table show these success ratios – for each dataset we show the API with the smallest success ratio (“Min”), with the highest success ratio (“Max”), and the average across all success ratios.

Dataset Strategy Min Max Avg
2015 (all) REGION_CHANGE 7% 100% 86%
HTTP_2_HTTPS 0% 100% 88%
HTTPS_2_HTTP 7% 100% 91%
2015 (w/o REGION_CHANGE 89% 100% 98%
offline endpoints) HTTP_2_HTTPS 78% 100% 97%
HTTPS_2_HTTP 94% 100% 99%
2018 REGION_CHANGE 93% 100% 99%
HTTP_2_HTTPS 93% 100% 99%
HTTPS_2_HTTP 94% 100% 99%
TABLE V: Observed Success Ratios of Protocol or Region Change in Case of Failures Across all APIs

Yahoo! is a good example to explain how regional differences can exist. In their PNUTS paper [14], they describe how Yahoo! rolls out services globally using the underlying PNUTS system for geo-replication across data centers. User requests are then routed to the respectively closest data center and mastership for data records is adapted based on user location. If now one data center has availability problems, then all read requests can be served elsewhere. The ability to serve update requests depends on whether the respective master record is stored within the affected data center.

Finding #6: General Availability Over the Years. Overall, availability improved from 2015 to 2018 for all three protocols. Only API-6 got slightly worse (still operating at 99.98% overall accessibility) and had some problems with ping as described in finding #2. Ignoring the two offline endpoints from 2015, availability improved from about 99.4% and 99.38% (HTTP and HTTPS respectively)to 99.94% and 99.93%. See table VI which gives an overview of overall accessibility rates across all APIs in 2015 and 2018.

Dataset Protocol Min Max Avg
2015 (all) HTTP 32.99% 99.992% 91.43%
HTTPS 34.17% 99.990% 93.95%
2015 (w/o HTTP 94.84% 99.992% 99.40%
offline endpoints) HTTPS 94.79% 99.990% 99.38%
2018 HTTP 99.69% 99.998% 99.94%
HTTPS 99.71% 99.993% 99.93%
TABLE VI: Overall Accessibility for HTTP and HTTPS Requests in 2015 and 2018

Conclusion. Overall, we see the main threat to developers in the longevity of APIs. When we started our experiment in 2015, we did not expect that so many API endpoints would be discontinued four years later. We were surprised when endpoints vanished without warning. Also, the correlation of availability across regions appears to be rather low – this makes it a little bit challenging for an API provider to monitor API availability. Finally, availability appears to have improved from 2015 to 2018 but developers should still be careful in their API selection as not all APIs offer the same availability levels.

5 Latency Findings

In this section, we describe findings of analyzing the latency of web API requests both in 2015 and in 2018, with a focus on the comparison of these findings. The majority of our findings are reflected in Figure 4, which uses box plots to summarize HTTPS latencies per API and region, comparing results from 2015 (shown in gray) with those of 2018 (shown in red). We focus on HTTPS to enable comparison with our previous work [8], and, again, as HTTPS is increasingly becoming the default transport protocol used in the web.

Fig. 4: Comparison of 2015 and 2018 HTTPS Request Latencies Across Regions in Milliseconds

Finding #1: Inter-Regional Differences. Latency of requests to a single API generally varies significantly depending on the geographic location of the client. We reported this finding in previous work [8] and can confirm this for 2018 as well. This variance, which we call geofactor, is for a specific API best described by first calculating the mean latency per region . Then the geofactor is calculated as .

In 2015, API-7 had the lowest geofactor at 1.65; in 2018, this honor went to API-8 at 1.47. In both years, API-5 had the highest geofactor at 28 (2015) and 32 (2018) respectively. The average geofactor across all APIs increased from 9 in 2015 to 10.9 in 2018.

Finding #2: Latency Differences within Regions over Time. Even within individual regions, the measured response times of requests to a single API can vary a lot over time. Consider, for example, Figure 5, which shows the histogram of the HTTPS latency measured for API-8 in region Ireland in 2018 (note that the y-axis uses a log scale). As can be seen, a large number of requests finished in 30-150ms. However, another large share of requests requires between 400-1500ms to finish, indicating the vast latency variance in this case.

Fig. 5: Histogram of HTTPS Latencies of API-8 in Ireland in 2018

Furthermore, as reported in our previous work [8]

, there are significant outliers in the data reaching response times in the hundreds of seconds, which practically render these APIs unavailable for those requests. In the 2018 data,

requests across seven APIs take over one minute to complete – just over half of these belong to API-1.

Finding #3: Geo-Distribution of API Endpoints. Measuring latency from different geographic locations allows, in some cases, to draw conclusions about the geographic distribution of API servers. Consider as an example Figures 7 and 7, which show the average daily latency for API-8 and API-9 respectively across regions. In case of API-8, latency values fall into two clusters: they are considerably worse in Sao Paulo and Sydney as compared to the rest of the world. Furthermore, the peaks of the regions’ latency curves are not aligned, indicating that the API is provided by different servers located in different locations. In contrast, in the case of API-9, the peaks of the latency curves of all regions are pretty much aligned, indicating that a single location is responsible for providing that API. Since the measured latency is consistently the lowest in Oregon, it can be assumed that this single API location is closer to Oregon than all other regions.

In the 2018 measurements, API-9 no longer exhibits the described behavior. Rather, latency peaks do not align in a clear way. In fact, in the 2018 measurements, no other API denotes latencies that align across all regions.

Fig. 6: Daily resampled HTTPS latency of API 8 across regions [8]
Fig. 7: Daily resampled HTTPS latency of API 9 across regions [8]

Finding #4: Changes Between Years. One way to depict the latency changes per API and region between 2015 and 2018 is to look at the 90% percentiles. Doing so allows us to delimit the distorting effect that outliers have. We find that, on average across regions, the latency 90-percentiles increase for 8 APIs, and decrease for 3 APIs. However, given also the changes in response sizes between the years, individual cases need to be considered: the changes for individual APIs are so different, that aggregated findings across sets of APIs are questionable. One notable example is API-4, where we had to replace the previously very large resource by a much smaller one, which is reflected in drastically reduced latency in 2018. Another example is API-7 where, despite the resource size having increased by over

between the years, latency has significantly decreased, across all regions. Possible causes for such improvements are the use of caching in the API backend or scaled-up servers to answer requests. API-7 is also an interesting example when considering the changes of latency variance between the years. On average across regions, the standard deviation of latencies of API-7 decreased by

. On the other hand, consider API-8, where the standard deviation grew on average by across regions.

In summary, we find that multiple APIs denote stark changes in latencies and the variance of latency between 2015 and 2018. This finding underlines once more – in addition to the latency changes we observed in our individual 3-month experiments – the necessity for application developers to a) continuously monitor the quality of service of the external services they depend on, and eventually to b) install mechanisms to mitigate occurring problems.

Conclusion. Measuring latency of web APIs reveals severe implications for application developers. They cannot assume that latency remains constant over time and have to expect stark latency variance when accessing APIs across the globe. If web APIs provide functionalities fundamental to an application, latency variation can have negative impacts on user attention [4] or even result in lost business [5]. This can be especially expected in cases where latency (temporarily) rises to multiple seconds. Application developers should consider mitigation strategies, as we discussed in previous work [8] and summarize in Section 8.4.

6 Security Findings

In this section, we describe findings from our security experiments. We base findings partly on the cipher suite security score and server security score introduced in Section 2.3.3.

Finding #1: Server Security Scores Differ Across APIs. The different APIs feature very different server security scores (as defined in Section 2.3.3). Figure 8 shows scores of APIs in 2015 in region US East. As can be seen, API-8 has the lowest score, with an average of . On the other hand, API-6 has the highest score, with an average of . Similarly, in 2018, average server security scores range from (API-3) to (API-4).

Fig. 8: Server Security Score Evolution in Region US East in 2015

Finding #2: Lasting Score Changes in 2015. To characterize whether and how security scores of an API change during our experiments, we define a lasting change to exist if the security score changes by at least between measurements, and if the new score is maintained for at least subsequent measurements. This definition of a lasting change is informed by exploring plots of the evolutions of security scores, which denote some outlying scores and some changes that persist for longer periods (i.e., days/weeks).

We find in the 2015 experiments that out of the 12 APIs, 5 (or 41.7%) denote lasting changes in their security scores (cf. also Figure 8). Three of these APIs (API-1, API-6, API-7) denote a single change, while the other two APIs (API-8, API-15) denote two lasting changes. In fact, the security scores of of these two APIs nearly perfectly overlap. Information obtained prior to anonymization of our data indicates that these two APIs are deployed on the same managed cloud infrastructure. Figure 9 shows, as an example, the 2015 evolution of the server security score of API-15, which has a (positive) lasting change around Oct 20, and another (negative) lasting change around Oct 26. Notably, in the 2018 data, we find not a single lasting change.

Fig. 9: Server Security Score Evolution of API-15 in 2015

Finding #3: Changes between 2015 and 2018. During our experiments, the server security scores featured lasting changes for only a minority of APIs in 2015, and for no APIs in 2018. However, the server security scores of all APIs changed between our two experiments. The median value of the changes (no matter if positive or negative) is , with a smallest change of (a negative change; API-7) and a maximum change of (also a negative change; API-3). In six cases, the score in 2018 is lower than in 2015, in the remaining five cases it is the other way round.

Finding #4: Server Security Scores are the Same Across Regions. We find that the security scores of APIs were, largely, the same across regions in both 2015 and 2018. I.e., we find no case where security scores were different for long periods of time, or where a lasting change (as defined in Finding #2) occurred in one region but not in others regions (within at least a few days). The largest time interval between lasting changes appeared for API-15, where the score lastingly decreased from to in region Ireland midday EST of Oct 25, 2015 while the same change occurred in Oregon only midday EST on Oct 27 (i.e., two days later).

Finding #4: Discontinuation of Cipher Suites. We observe six cipher suites that are only present in the 2015 data. Table VII shows these suites, their cipher suite security score, and the APIs that support them in the 2015 data. Notably, the cipher suite security scores range from -1 to 1.1, i.e., these suites include the whole spectrum of scores (and not only, for example, badly scoring suites).

APIs 2015
with support
DHE-RSA-CAMELLIA256-SHA 1.1 4, 6, 9
DHE-RSA-CAMELLIA128-SHA 1.0 4, 6, 9
CAMELLIA256-SHA 0.1 4, 9, 13
CAMELLIA128-SHA 0.0 4 7
ECDHE-RSA-RC4-SHA -1 1, 8, 10, 15
RC4-MD5 -1 1, 8, 10, 15
TABLE VII: Cipher Suites Appearing only in 2015 Experiments

Finding #5: Reduced Use of Insecure Cipher Suites. Our cipher suite security score assigns a minimum value of -1 to suites that have known vulnerabilities. For example, the RC4 algorithm is known to be vulnerable and was prohibited from use in TLS by the Internet Engineering Task Force in 2015121212For details, cf. When counting the frequency in which cipher suites with a score of -1 appear across APIs and across regions, we find 31,316 occurrences in 2015 and only 6775 occurrences in 2018. While this improvement is not reflected in the evolution of server security scores between the years (cf. Finding #3), it does indicate that over time the “worst offenders” are removed.

Conclusion. Quantifying security is a notoriously hard if not impossible challenge. We defined cipher suite/server security scores not to make absolute statements about security of APIs, but to be able to compare APIs and assess the changes over time. The server security scores of an API are closely related across regions, with only short temporal discrepancy. Also, we only found lasting changes of server security scores in the 2015 experiments. However, considering the full picture of measurements between 2015 and 2018, we find that all APIs feature changes in security scores, and that these changes are not necessarily leading to higher security. We find, though, that the use of insecure cipher suites has dropped from 2015 to 2018.

7 Findings from Reaching Out

In this section, we give an overview of the results of reaching out to all API providers from our original paper [8].

In our assessment, we decided that email or an official API contact form is the best way of contacting a provider as it provides (i) a dedicated contact channel (other than a forum that might or might not be monitored) and (ii) a way of communicating potentially sensitive information of the API user. We believe that Twitter and online forums are the second best options as on these channels contact attempts are more likely to be overlooked and also, e.g., in the case of Twitter, require users to entrust potentially sensitive data to a third party. Finally, we ranked all other contact methods worse than this (but better than no contact method). Following this reasoning, we first tried to find an official contact form or support email address for the API. If that was not successful we tried Twitter or online forums. If that also did not work we tried any other contact method that we could find via Google search.

Fig. 10: Availability of Contact Methods and Results of Reaching Out to Providers

Finding #1: Availability of Contact Methods. We were able to find contact forms or official support email addresses for eight (out of fifteen) APIs, four had Twitter profiles. For the other APIs, we contacted one via an existing “contact of a contact” on LinkedIn, for one we found a self-proclaimed “senior developer” of the API on GitHub and his email address via Google search. Finally, we found one personal website on which the respective person claimed that API (and provided some contact details).

Finding #2: Quality of Responses (Email/Contact Form). Of our eight contact requests via official support emails or contact forms, two resulted in interesting conversations where the API provider appeared interested in our results and provided helpful comments. Three of the eight requests resulted in either an automated email or an email that was a bit more personalized which indicated that our request had been forwarded to the respective development teams and that we would get a response soon. Another three requests were completely ignored.

Finding #3: Quality of Responses (Twitter). Of the four requests we sent via Twitter to the respective API support handles, one provider was very interested and provided helpful comments leading to an email-based discussion. Another provider asked us to send them a private message with further details but we did not receive an answer to that. The last two providers ignored our requests completely.

Finding #4: Quality of Responses for Other Contact Methods. Neither of the three contact requests did result in any reaction of the API provider. See also Figure 10 which gives an overview of all responses.

Finding #5: Quality of Responses (Summary). All in all, only three out of fifteen providers provided helpful comments and were actually approachable. There was no correlation with the provider size, country, or industry.

Finding #6: Insights Gained. Aside from the meta-information on whether we received answers or not, we also learned some architectural details. For instance, one of the APIs provides their content strictly read-only. In their deployments, they bundle API code and a database instance. This makes it relatively easy to guarantee high availability and performance as the number of replicas is only restricted by the available budget. Other APIs have it much harder as their backends are subject to the well-known tradeoffs of PACELC [15] and other scalability restrictions.

Conclusion. Overall, developers should not rely on the ability to reach API providers in case of problems. Based on our observations, we believe that it is a rare exception when developers can get support unless they are explicitly paying for it. We would recommend to primarily use APIs that are at least well documented and preferably widely used.

8 Discussion

In this section, we discuss threats to validity of results and what we did to mitigate those threats. We also discuss implications on application engineering.

8.1 Dying Processes

In this work, we set out to repeat experiments originally performed in 2015 and published in previous work [8]. We actually initiated this repetition twice: once in late 2017, and once in early 2018. During the experiments performed in 2017 – the results of which are not reported here – we noticed that our measurement process had crashed on some virtual machines, without producing any error logs. This happened despite our implementation being written to catch all Java exceptions to at least log them in terms of handling. The processes, however, had crashed without a trace. This could have three reasons: First, there might be a bug that we have not found yet. Second, there might be a bug in the JVM that we used. Third, Amazon might have restarted the VM that our tool was running on.

In consequence of a process dying, all HTTP and HTTPS measurements from the affected region are stopped, which renders the entire experiment data unusable. Upon noticing this threat in our 2017 experiments, we stopped the experiment and restarted from scratch. We extended our measurement client with a simple HTTP server, running in the same process, and used the Uptime Robot service to continuously monitor the availability of that server (cf. Section 3.1). Uptime Robot uses a 5-minute monitoring interval. In case of a crash of the measurement client, we could restart it to continue collecting data.

Fortunately, this threat did not materialize in our 2015 experiments. We performed the 2018 experiments having the HTTP server in combination with Uptime Robot in place as a safety mechanism. During the 2018 experiment, we did also not observe any process dying.

8.2 Dying Threads

A threat in addition to a whole process (i.e., the JVM) dying is that individual threads, responsible for measuring one API endpoint, die during an experiment. Being pointed to this possibility, we re-assessed our 2015 data and found indeed cases where individual threads had disappeared. The consequence of this observation is twofold: It requires us to correct findings reported in our original work [8]. It also led us to improve our experiment setup and data analysis further to be able to react more quickly to dying threads.

Correction of Findings in Previous Work The unexpected death of measurement threads, inexplicably happening without any log entries, meant that data collected in the 2015 experiments has numerous missing data points. Specifically, manual analysis of the raw collected data reveals that (or ) of the measurement threads ( regions, HTTP, HTTPS,

ICMP endpoints) died during the experiments – dying threads appeared only for HTTP and HTTPS measurements. The death of threads produced no error logs, and subsequent data points were simply missing. Our original data analysis wrongly interpolated these missing data points to mean that the server was unreachable, leading to us over-reporting unavailabilities of APIs in Table 2 in our paper 

[8]. In Section 4 of this paper, we present corrected availability figures, where we no longer attribute missing data points to mean that the API was unavailable.

Improvements of Experiment Setup and Data Analysis We applied a set of measures to improve our experiment setup and subsequent data analysis to prevent repeating the described errors:

  • We implemented a website, returned by the HTTP server implemented to check for dying processes (cf. Section 8.1), that reports the last timestamp and measurement value of every single measurement thread running on the same server. This website grants us on-demand insight into the proper working of all threads on a benchmarking client.

  • We re-wrote our analysis scripts for availability from scratch in Java, thus having an additional implementation (besides our updated Python script that used the pandas library). For both versions of the data analysis code, we wrote additional test cases and compared their outputs to improve their reliability.

8.3 Other Threats to Validity

As in our original paper, our experiments targeted selected endpoints. The findings from our experiments can, thus, not necessarily be generalized to the overall API from which the endpoint stems. For example, providers may choose to remove an endpoint we benchmarked, while other endpoints of the same API remain available. Another aspect is that we only used GET requests – due to caching, actual availabilities may be worse. Nonetheless, we deem our results valid examples of how web API qualities can impact applications, which ultimately rely on specific endpoints. Depending on the API, GET may even be the standard way of accessing it, e.g., for maps APIs.

We, furthermore, limited our experiments to endpoints that do not require authentication. One might argue that these endpoints may be of less importance to their providers and may, thus, undergo less scrutiny than other endpoints. Nonetheless, these endpoints may well be used by applications and the here presented findings should, hence, be considered relevant to application developers. Still, our observations should not be generalized to endpoints with mandatory authentication in place.

8.4 Implications for Application Engineering

In our original paper, we discussed that API consumers are directly affected by provider decisions and have no control over the consumed service which was also visible in the results [8]. Namely, latency and availability varied depending on the geo-origin of requests and in general showed a high variance. Also, endpoints vanished during our experiment. As a consequence, we recommended to rely on a variety of mechanisms such as caching, request queuing, monitoring, and API notification services131313e.g., We also discussed preliminary ideas for a geo-distributed middleware which acts as a proxy and performs protocol changes or tunnels requests through other regions when necessary and feasible.

Overall, none of these recommendations have become invalid. What is most disturbing, though, is the sheer number of API endpoints that does no longer exist in 2018 – and neither of these endpoints is for an API that might be simply obsolete such as a service that returns information on outdated technology. Based on this, we can only recommend to actively look for API alternatives (e.g., Google Maps and Bing Maps) or to build upon APIs that could be self-hosted if necessary (e.g., Open Street Maps). In terms of reaching out, developers should not expect much customer support (this might be better for APIs with a paid plan) so that we would recommend to carefully check existing documentation and developer forums before committing to an API. Finally, security-wise, we have seen that many APIs still support obsolete cipher suites. Since the server selects the cipher suite, we would recommend to restrict the set of supported cipher suites on the client to modern ones only so that downgrades are no longer possible. This also asserts that users are less affected by varying cipher suite preferences of providers.

9 Related Work

In this section, we give an overview of related work starting web API evolution before continuing with benchmarking in general and web API benchmarking in particular.

9.1 Web API Evolution

Some works have studied how web APIs evolve, characterizing change patterns and resulting challenges for application developers [16], and assessing how developers react to these changes [17]. Focusing on implications on applications, Espinha et al. have shown that mobile applications show diverse behavior in light of web API evolution [6]. Nearly a third of applications crash in light of the removal of fields from response messages, highlighting severe consequences that affect user experiences. In a similar vain, Aue et al. report from a single payment API provider’s point of view about the cause and scope of erroneous integrations – reflected by millions of error logs [3]. These works underline the important role web APIs play for many applications. In contrast to these works, we do not address web API evolution, i.e., how the functionality of a web API changes, but the rather focus on web API qualities, i.e., its changing non-functionalities. We argue that these two perspectives complement one another, and can have similar importance. Errors due to faulty integration or issues caused by unavailabilities, security issues, or high latency can equally threaten how users experience applications. Similar, both API providers and consuming developers are challenged to avoid such issues, relying for example on the mitigation strategies hinted at in Section 8.4.

9.2 Web API Characteristics and Ecosystems

A wide array of related works assess what web APIs exist, how they are used, and how they can be characterized. Early studies of API ecosystems focused on ProgrammableWeb, a community-maintained catalog of web APIs. Analyses have explored the evolution of this ecosystem [18, 19], how APIs in ProgrammableWeb are (reportedly) used in mashups [20], or utilized such usage relations to recommend web APIs to developers [21, 2]. Other studies assessed web API usage outside of ProgrammableWeb, and specifically in the context of mobile applications. For example, Oumaziz et al. perform static analysis on mobile applications to assess if and to what extent they interact with web APIs [22]. Rapoport et al. combine static analysis with a dynamic execution of selected mobile applications, exploring how to best detect consumption of web APIs [23]. Finally, Wittern et al. studied how to detect the use of web APIs in JavaScript-based application code mined from GitHub using static analysis [24]. These works underline the importance of web APIs for application developers, and an increasing recognition of related challenges and research opportunities [25].

Yet another set of works assess characteristics of existing web APIs. Rodriguez et al. extract web API requests from large volumes of HTTP traffic logs and assess their adherence to various design principles, including proper use of HTTP verbs or how URLs are structured [26]. Neumann et al. manually identify web APIs among popular web sites and assess their documentations for a similar set of design principles [27]. We again see our work to complement these approaches, which focus on design aspects of APIs, as this work focuses on runtime qualities.

9.3 Benchmarking

Benchmarking comprises a number of different areas. The oldest area is concerned with quantifying performance of (virtual) machines. These include many SPEC141414 benchmarks or collections such as the Phoronix Test Suite151515 but also more recent developments, e.g., [28] which uses WordPress as a realistic benchmark application. Another well-studied area is the benchmarking of database systems which, in the last few years, has evolved from relational database benchmarks such as the well-established TPC161616 benchmarks towards modern NoSQL datastores. For instance, the de facto standard YCSB [29] and its extensions [30, 31] introduced database benchmarking based on CRUD interfaces, which are more compatible with modern NoSQL stores like Apache Cassandra [32]. Other approaches such as OLTPBench [33] or BenchFoundry [34, 35] aim to build comprehensive multi-quality benchmarking platforms that also include measurement approaches for qualities beyond performance, e.g., data consistency [36, 10, 37, 38, 39] or elastic scalability [11, 12]. Beyond this, there are a number of approaches studying performance impacts of TLS on NoSQL datastores [40, 41, 42], web services [43], and web servers [44].

Neither of these approaches is directly comparable to the work presented in this paper as these approaches all have in common that they stress the system under test while our approach is more lightweight and does not create significant load on web APIs. In this regard, it is more comparable to monitoring approaches [45]. For an extended discussion of the broad area of benchmarking – this list is by no means exhaustive, we refer to our recent book on cloud service benchmarking [9] or foundational publications on the principles of benchmarking such as [46, 47, 48, 49, 50].

To our knowledge, this paper and our original paper [8] are the only publications that aim to quantify quality of service of web APIs through geo-distributed long-term experiments. Other measurement approaches such as 171717 can be used to run load tests against web APIs. This, however, is explicitly forbidden in the terms of service of all APIs that we have looked at (which includes a longer list than those used for our experiments). As such, it is unlikely to provide insights into the behavior of web APIs “in the wild” or needs to be run by the provider.

10 Conclusion

Over the last few years, web APIs have found widespread adoption in mobile and web applications. Hence, quality behavior of web APIs more and more affects user experience of such applications – from a developer perspective, this is highly problematic as they have absolutely no control over the API and its quality.

In 2016, we published a conference paper on benchmarking of web APIs [8]. For this paper, we extended our original benchmarking tool and repeated the three-month experiment. Of the original 15 APIs from 2015, there were in 2018 only 11 left. For all these, we reported detailed results and corresponding insights on availability, performance, and security behavior. We also analyzed to which degree the API providers can be contacted and actually respond to inquiries.


  • [1] R. T. Fielding and R. N. Taylor, Architectural Styles and the Design of Network-based Software Architectures.   University of California, Irvine Irvine, USA, 2000, vol. 7.
  • [2] E. Wittern, J. Laredo, M. Vukovic, V. Muthusamy, and A. Slominski, “A Graph-based Data Model for API Ecosystem Insights,” in Proc. of ICWS.   IEEE, 2014, pp. 41–48.
  • [3] J. Aué, M. Aniche, M. Lobbezoo, and A. van Deursen, “An Exploratory Study on Faults inWeb API Integration in a Large-Scale Payment Company,” in 2018 IEEE/ACM 40th International Conference on Software Engineering: Software Engineering in Practice Track (ICSE-SEIP), May 2017, pp. 13–22.
  • [4] J. Nielsen, Usability Engineering, 1st ed.   Elsevier, 1994.
  • [5] J. Brutlag, “Speed Matters for Google Web Search,” Google, Inc., Tech. Rep., 2009.
  • [6] T. Espinha, A. Zaidman, and H.-G. Gross, “Web API Fragility: How Robust is Your Mobile Application?” in Proc. of MOBILESoft.   IEEE, 2015, pp. 12–21.
  • [7] P. Suter and E. Wittern, “Inferring Web API Descriptions from Usage Data,” in Proc. of the 3rd IEEE Workshop on Hot Topics in Web Systems and Technologies (HotWeb), 2015, pp. 7–12.
  • [8] D. Bermbach and E. Wittern, “Benchmarking web api quality,” in Proceedings of the 16th International Conference on Web Engineering (ICWE 2016).   Springer, 2016.
  • [9] D. Bermbach, E. Wittern, and S. Tai, Cloud Service Benchmarking: Measuring Quality of Cloud Services from a Client Perspective.   Springer, 2017.
  • [10] D. Bermbach, “Benchmarking eventually consistent distributed storage systems,” Ph.D. dissertation, Karlsruhe Institute of Technology, 2014.
  • [11] D. Kossmann, T. Kraska, and S. Loesing, “An Evaluation of Alternative Architectures for Transaction Processing in the Cloud,” in Proc. of SIGMOD.   ACM, 2010, pp. 579–590.
  • [12] J. Kuhlenkamp, M. Klems, and O. Röss, “Benchmarking Scalability and Elasticity of Distributed Database Systems,” 2014, pp. 1219–1230.
  • [13] D. Bermbach, R. Kern, P. Wichmann, S. Rath, and C. Zirpins, “An Extendable Toolkit for Managing Quality of Human-Based Electronic Services,” in Proc. of the 3rd Human Computation Workshop, ser. HCOMP ’11, 2011.
  • [14] B. F. Cooper, R. Ramakrishnan, U. Srivastava, A. Silberstein, P. Bohannon, H.-A. Jacobsen, N. Puz, D. Weaver, and R. Yerneni, “Pnuts: Yahoo!’s hosted data serving platform,” Proceedings of the VLDB Endowment, vol. 1, no. 2, pp. 1277–1288, Aug. 2008. [Online]. Available:
  • [15] D. Abadi, “Consistency tradeoffs in modern distributed database system design: Cap is only part of the story,” IEEE Computer, vol. 45, no. 2, pp. 37–42, Feb. 2012. [Online]. Available:
  • [16] J. Li, Y. Xiong, X. Liu, and L. Zhang, “How Does Web Service API Evolution Affect Clients?” in 2013 IEEE 20th International Conference on Web Services.   IEEE, 2013, pp. 300–307.
  • [17] S. Wang, I. Keivanloo, and Y. Zou, “How Do Developers React to RESTful API Evolution?” in Proc. of ICSOC.   Springer, 2014, pp. 245–259.
  • [18] S. Yu and C. J. Woodard, “Innovation in the Programmable Web: Characterizing the Mashup Ecosystem,” in International Conference on Service-Oriented Computing.   Springer, 2008, pp. 136–147.
  • [19] M. Weiss and G. Gangadharan, “Modeling the mashup ecosystem: Structure and growth,” R&d Management, vol. 40, no. 1, pp. 40–49, 2010.
  • [20] K. Huang, Y. Fan, and W. Tan, “An Empirical Study of Programmable Web: A Network Analysis on a Service-Mashup System,” in 2012 IEEE 19th International Conference on Web Services.   IEEE, 2012, pp. 552–559.
  • [21] C. Li, R. Zhang, J. Huai, and H. Sun, “A Novel Approach for API Recommendation in Mashup Development,” in 2014 IEEE International Conference on Web Services.   IEEE, 2014, pp. 289–296.
  • [22] M. A. Oumaziz, A. Belkhir, T. Vacher, E. Beaudry, X. Blanc, J.-R. Falleri, and N. Moha, “Empirical Study on REST APIs Usage in Android Mobile Applications,” in International Conference on Service-Oriented Computing.   Springer, 2017, pp. 614–622.
  • [23] M. Rapoport, P. Suter, E. Wittern, O. Lhótak, and J. Dolby, “Who you gonna call? Analyzing Web Requests in Android Applications,” in Proceedings of the 14th International Conference on Mining Software Repositories.   IEEE Press, 2017, pp. 80–90.
  • [24] E. Wittern, A. T. T. Ying, Y. Zheng, J. Dolby, and J. A. Laredo, “Statically Checking Web API Requests in JavaScript,” in Proceedings of the 39th International Conference on Software Engineering, ser. ICSE ’17.   Piscataway, NJ, USA: IEEE Press, 2017, pp. 244–254. [Online]. Available:
  • [25] E. Wittern, A. Ying, Y. Zheng, J. A. Laredo, J. Dolby, C. C. Young, and A. A. Slominski, “Opportunities in Software Engineering Research for Web API Consumption,” in Proceedings of the 1st International Workshop on API Usage and Evolution, ser. WAPI ’17.   Piscataway, NJ, USA: IEEE Press, 2017, pp. 7–10. [Online]. Available:
  • [26] C. Rodríguez, M. Baez, F. Daniel, F. Casati, J. C. Trabucco, L. Canali, and G. Percannella, “Rest apis: a large-scale analysis of compliance with principles and best practices,” in International Conference on Web Engineering.   Springer, 2016, pp. 21–39.
  • [27] A. Neumann, N. Laranjeiro, and J. Bernardino, “An Analysis of Public REST Web Service APIs,” IEEE Transactions on Services Computing, 2018.
  • [28] A. H. Borhani, P. Leitner, B.-S. Lee, X. Li, and T. Hung, “WPress: An Application-Driven Performance Benchmark for Cloud-Based Virtual Machines,” in Proc. of EDOC.   IEEE, 2014, pp. 101–109.
  • [29] B. F. Cooper, A. Silberstein, E. Tam, R. Ramakrishnan, and R. Sears, “Benchmarking Cloud Serving Systems with YCSB,” in Proc. of SOCC.   ACM, 2010, pp. 143–154.
  • [30] S. Patil, M. Polte, K. Ren, W. Tantisiriroj, L. Xiao, J. López, G. Gibson, A. Fuchs, and B. Rinaldi, “YCSB++: Benchmarking and Performance Debugging Advanced Features in Scalable Table Stores,” in Proc. of SOCC.   ACM, 2011, pp. 1–14.
  • [31] A. Dey, A. Fekete, R. Nambiar, and U. Röhm, “Ycsb+ t: Benchmarking web-scale transactional databases,” in 2014 IEEE 30th International Conference on Data Engineering Workshops.   IEEE, 2014, pp. 223–230.
  • [32] A. Lakshman and P. Malik, “Cassandra: A decentralized structured storage system,” SIGOPS Operating Systems Review, vol. 44, no. 2, pp. 35–40, Apr. 2010. [Online]. Available:
  • [33] D. E. Difallah, A. Pavlo, C. Curino, and P. Cudre-Mauroux, “Oltp-bench: An extensible testbed for benchmarking relational databases,” Proceedings of the VLDB Endowment, vol. 7, no. 4, pp. 277–288, 2013.
  • [34] D. Bermbach, J. Kuhlenkamp, A. Dey, A. Ramachandran, A. Fekete, and S. Tai, “BenchFoundry: A Benchmarking Framework for Cloud Storage Services,” in Proceedings of the 15th International Conference on Service Oriented Computing (ICSOC 2017).   Springer, 2017.
  • [35] D. Bermbach, J. Kuhlenkamp, A. Dey, S. Sakr, and R. Nambiar, “Towards an Extensible Middleware for Database Benchmarking,” in TPCTC 2014.   Springer, 2014, pp. 82–96.
  • [36] D. Bermbach and S. Tai, “Benchmarking Eventual Consistency: Lessons Learned from Long-Term Experimental Studies,” in Proc. of IC2E.   IEEE, 2014, pp. 47–56.
  • [37] H. Wada, A. Fekete, L. Zhao, K. Lee, and A. Liu, “Data Consistency Properties and the Trade-offs in Commercial Cloud Storages: the Consumers’ Perspective,” in Proc. of CIDR, 2011, pp. 134–143.
  • [38] E. Anderson, X. Li, M. A. Shah, J. Tucek, and J. J. Wylie, “What consistency does your key-value store actually provide?” in Proceedings of the 6th Workshop on Hot Topics in System Dependability (HOTDEP), ser. HotDep’10.   Berkeley, CA, USA: USENIX Association, 2010, pp. 1–16. [Online]. Available:
  • [39] K. Zellag and B. Kemme, “How Consistent is Your Cloud Application?” in Proc. of SOCC.   ACM, 2012.
  • [40] S. Müller, D. Bermbach, S. Tai, and F. Pallas, “Benchmarking the Performance Impact of Transport Layer Security in Cloud Database Systems,” in Proc. of IC2E.   IEEE, 2014, pp. 27–36.
  • [41] F. Pallas, D. Bermbach, S. Müller, and S. Tai, “Evidence-based security configurations for cloud datastores,” in Proceedings of the the 32nd ACM Symposium on Applied Computing.   ACM, 2017.
  • [42] F. Pallas, J. Günther, and D. Bermbach, “Pick your choice in hbase: Security or performance,” in Proceedings of the IEEE International Conference on Big Data (Big Data 2016).   IEEE, 2017.
  • [43] M. B. Juric, I. Rozman, B. Brumen, M. Colnaric, and M. Hericko, “Comparison of Performance of Web Services, WS-Security, RMI, and RMI–SSL,” Journal of Systems and Software, vol. 79, no. 5, pp. 689–700, 2006.
  • [44] C. Coarfa, P. Druschel, and D. S. Wallach, “Performance Analysis of TLS Web Servers,” ACM Transactions on Computer Systems (TOCS), vol. 24, no. 1, pp. 39–69, 2006.
  • [45] J. Kuhlenkamp, K. Rudolph, and D. Bermbach, “AISLE: Assessment of Provisioned Service Levels in Public IaaS-based Database Systems,” in Proc. of ICSOC.   Springer, 2015, pp. 154–168.
  • [46] C. Binnig, D. Kossmann, T. Kraska, and S. Loesing, “How is the Weather Tomorrow?: Towards a Benchmark for the Cloud,” in Proc. of DBTEST.   ACM, 2009, pp. 1–6.
  • [47] J. Gray, The Benchmark Handbook for Database and Transaction Systems, 2nd ed.   Morgan Kaufmann, 1993, ch. Database and Transaction Processing Handbook.
  • [48] J. v. Kistowski, J. A. Arnold, K. Huppler, K.-D. Lange, J. L. Henning, and P. Cao, “How to build a benchmark,” in Proceedings of the 6th ACM/SPEC International Conference on Performance Engineering (ICPE 2015).   ACM, 2015, pp. 333–336.
  • [49] K. Huppler, “The art of building a good benchmark,” in Proceedings of the First TPC Technology Conference on Performance Evaluation and Benchmarking (TPCTC 2009).   Springer, 2009, pp. 18–30.
  • [50] E. Folkerts, A. Alexandrov, K. Sachs, A. Iosup, V. Markl, and C. Tosun, “Benchmarking in the cloud: What it should, can, and cannot be,” in Proceedings of the 4th TPC Technology Conference on Performance Evaluation and Benchmarking (TPCTC 2012).   Springer, 2013, pp. 173–188.