SLA4OAI-Analyzer: Automated Validation of RESTful API Pricing Plans

SLA4OAI-Analyzer: Automated Validation of RESTful API Pricing Plans Rafael Fresno-Aranda(B), Pablo Fern´andez , and Antonio Ruiz-Cort´es SCORE Lab, I3US Institute, Universidad de Sevilla, Seville, Spain {rfresno,pablofm,aruiz}@us.es Abstract. Nowadays, public web APIs are considered as business assets by many organizations. They provide data and functionality which other developers can integrate within their own services. These APIs are commercialized through pricings, which include a series of plans. Each plan contains features and limitations, coupled with a price. Developers who wish to use the API need to choose which plan better suits their needs. The formal description of pricings is not standardized, which hinders the ability to automate their analysis. The SLA4OAI specification aims to provide an extension for OpenAPI that allows pricings to be described. This specification paves the way for an ecosystem of tools that leverage the information of a pricing. In this paper, we present SLA4OAI-Analyzer, a public API that automatically checks an SLA4OAI specification file for conflicts at different levels. We also provide an online Jupyter notebook to validate the API using different examples. Keywords: Automation ·Validity ·REST ·API ·Pricing 1 Introduction Nowadays, public web APIs are considered as business assets by many organizations. They provide data and functionality which other software developers can integrate within their own services. This has been boosted by the growing popularity of cloud-based and service-oriented architectures, which promote isolation and integration of different components through APIs. In this scenario, organizations commercialize their APIs through pricings, which include a series of plans. Each plan comprises a set of features and usage restrictions (limitations), coupled with a price that is usually a periodic subscription or pay-as-you-go. This work has been partially supported by grants RTI2018-101204-B-C21, RTI2018- 101204-B-C22, PID2021-126227NB-C21, PID2021-126227NB-C22, TED2021-131023B- C21, TED2021-131023B-C22, PDC2022-133521-I00 funded by MCIN/AEI/10.130 39/501100011033 and “ERDF a way of making Europe”; grants PYC20 RE 084 US, P18-FR-2895, US-1264651, US-1381595 funded by Junta de Andalucia/ERDF,UE; and FPU19/00666 funded by MCIN/AEI/10.13039/501100011033 and by “ESF Investing in your future”. https://doi.org/10.1007/978-3-031-34444-2_28 364 R. Fresno-Aranda et al. Developers who wish to use the API need to choose between the different plans and subscribe to the one that better suits their needs. Out of the different types of web APIs, RESTful APIs [8] are currently the most popular. They define each operation as an HTTP request that contains a URL, an HTTP method and a set of required or optional parameters. The RESTful paradigm integrates well within cloud-based architectures, in which different services communicate with each other through HTTP requests. There has been an ongoing effort to standardize the functional description of RESTful APIs. As of today, the de-facto standard is the OpenAPI Specification (OAS) [2], which has been adopted by many organizations to describe their APIs. This has fostered the creation of an ecosystem of tools that leverage the information in an OAS description for several purposes. Some examples include automated generation of mock servers or test cases [11]. Nonetheless, the non-functional description of an API (e.g. its pricing) is not part of OAS and its definition is up to the API provider [10]. This makes it harder to leverage the information included in a pricing, because each organization may describe it in a completely different way. Furthermore, it is difficult to check the validity and correctness of a pricing when its description is not standardized. In our previous work, we presented SLA4OAI1[6],aproposed extension of OAS that includes non-functional information and aims to overcome the aforementioned issues. It is a work-in-progress specification, written in JSON or YAML, that is under discussion by organizations and practitioners [7]. The formal description of an API pricing is useful, for example, to check for its correctness or automatically choose the best plans based on user needs [9]. In this demo, we present SLA4OAI-Analyzer, a RESTful API that automatically validates an SLA4OAI specification file and detects different types of conflicts. We also provide an online Jupyter notebook [5] to validate the API. The demo video is available at https://vimeo.com/803184037. 2 SLA4OAI-Analyzer 2.1 Validity of a Pricing The validity of an SLA4OAI specification file, and thus the validity of a pricing, is defined as the absence of conflicts between the different elements of the pricing. A pricing consists of a series of plans, each of them having a series of limitations, and each limitation having a series of limits. A pricing is therefore valid when all of its elements are valid. For example, a pricing is not valid if a single limitation is not valid and has a conflict. An API provider would benefit from the automated validation of pricings, in order to ensure the coherence of its elements and, potentially, prevent users from exploiting the API. Another element of an API worth mentioning is its capacity. The capacity of an API is the maximum workload that it can handle over a specific period of 1For historical reasons, we keep the name SLA4OAI even though the specification does not support Service Level Agreements, which are out of the scope of this paper. SLA4OAI-Analyzer: Automated Validation of RESTful API Pricing Plans 365 time. It usually depends on the internal architecture and the deployment setup of the API. For example, a capacity of 1000 requests per second (RPS) means that the API can serve up to 1000 requests each second to its users. In the following paragraphs, we present the validity criteria in a hierarchy. We start from fine-grained elements (limits and limitations) to coarse-grained ones (plans and pricing). Each criterion has multiple subcriteria, and all of them must be valid for the criterion to be valid. VC1 - Valid limit Alimit is valid if its threshold is a natural number (VC1.1). VC2 - Valid limitation Alimitation is valid if: all its limits are valid (VC2.1); there are no limit consistency conflicts between any pair of its limits, i.e. a limit over a longer period of time has a lower threshold than a limit over a shorter period (VC2.2); there are no ambiguity conflicts between any pair of its limits, i.e. multiple limits with different thresholds over the same period of time (VC2.3); and there is no capacity conflict, i.e. a limit is less restrictive than the capacity of the API (VC2.4). VC3 - Valid plan Aplan is valid if: all its limitations are valid (VC3.1); and there are no limitation consistency conflicts between any pair of its limitations, i.e. a limitation over a metric allows another limitation over a related metric (by a certain factor) to be exceeded (VC3.2). VC4 - Valid pricing Apricing is valid if: all its plans are valid (VC4.1); and there are no cost consistency conflicts between any pair of its plans, i.e. a limitation in a plan with a lower cost is less restrictive than the equivalent limitation in a plan with a higher cost (VC4.2). Listing 1.1 shows a simplified example of a pricing with a limit consistency conflict (VC2.2). Other examples can be found in our notebook [5].  1Limitations: 2Quota: 100 requests / 1 day 3Quota: 10 requests / 1 week   Listing 1.1. Example of validity criterion VC2.2 (limit consistency conflict). 2.2 Pricing Validation API The SLA4OAI-Analyzer API is available at [3]. Its code is publicly available at [4]. The API takes a URL that points to an SLA4OAI specification file as an input and checks for all conflicts that were presented in the previous subsection. The API returns a Boolean value that indicates whether the file is valid, and a detailed log showing the validity of each individual element of the pricing. To validate the API, we provide an online Jupyter notebook that is available at [5]. Note that the notebook is shared with execute access, meaning that the cells can be executed but not modified. Nonetheless, they may be modified if the notebook is duplicated into your own Deepnote account. The notebook includes two examples for each validity subcriterion: one example has a conflict and the other does not. Because the full SLA4OAI specification files are complex and 366 R. Fresno-Aranda et al. contain additional information that is not relevant for the detection of conflicts, each example includes a short pseudocode fragment, similar to listing 1.1, that shows the pricing elements that are actually relevant for this demo. The full SLA4OAI files are available at [1]. The examples in the notebook use these files. Alternatively, the API also accepts a full SLA4OAI file directly within the request body. There is a cell at the end of the notebook that contains an example. 3 Conclusions and Future Work In this paper we presented SLA4OAI-Analyzer, a public API that automatically analyzes an SLA4OAI specification file and detects different types of conflicts at different levels of the specification. This tool is an example of how to leverage the information of a pricing when a formal description is available. The current implementation of SLA4OAI-Analyzer has some limitations. It follows a strict syntax-guided approach, so small changes in the specification derive in important updates to the API. In the future, we aim to transform a pricing into a constraint satisfaction problem (CSP), which should allow for better maintainability and scalability of the API. References 1. Full SLA4OAI Specification Files. https://github.com/isa-group/icwe23-demo- sla4oaianalyzer 2. OpenAPI Specification 3.1.0. https://spec.openapis.org/oas/v3.1.0 3. SLA4OAI-Analyzer API. https://sla4oai-analyzer-api.services.governify.io 4. SLA4OAI-Analyzer API Repository. https://github.com/isa-group/sla4oai- analyzer-api 5. SLA4OAI-Analyzer Deepnote Notebook. https://deepnote.com/workspace/ rafael-fresno-ab85b312-0a6a-4a0d-8975-786d40a9e336/project/SLA4OAI- Conflicts-e39d1e11-8472-47c5-abd6-b4be10851a8d/notebook/Notebook%201- a14aeec4a0394c47bebbabbfe0c4dfce 6. SLA4OAI Research Specification. https://github.com/isa-group/SLA4OAI- ResearchSpecification 7. SLA4OAI Technical Committee. https://github.com/isa-group/SLA4OAI-TC 8. Fielding, R.T.: Architectural styles and the design of network-based software architectures. University of California, Irvine (2000) 9. Fresno-Aranda, R., Fern´andez, P., Dur´an, A., Ruiz-Cort´es, A.: Semi-Automated Capacity Analysis of Limitation-Aware Microservices Architectures. In: Ba˜nares, J.´ A., Altmann, J., Agmon Ben-Yehuda, O., Djemame, K., Stankovski, V., Tuffin, B. (eds.) Economics of Grids, Clouds, Systems, and Services. GECON 2022. LNCS, vol. 13430, pp. 75–88. Springer, Cham (2022). https://doi.org/10.1007/978-3-031- 29315-3 7 10. Gamez-Diaz, A., Fernandez, P., Ruiz-Cortes, A.: An analysis of RESTful APIs offerings in the industry. In: Maximilien, M., Vallecillo, A., Wang, J., Oriol, M. (eds.) ICSOC 2017. LNCS, vol. 10601, pp. 589–604. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-69035-3 43 11. Martin-Lopez, A., Segura, S., Ruiz-Cort´es, A.: RESTest: automated black-box testing of RESTful web APIs. In: Proceedings 30th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), pp. 682–685 (2021)