RESTful API Testing Methodologies: Rationale, Challenges, and Solution Directions

Most of the modern applications use Representational State Transfer (REST) as the standard for designing complex web services. The testing and validation in development phase can use debugging techniques to detect and resolve the errors. An obstacle to use conventional testing methodologies to check the consistency in production phase is that RESTful Application Programming Interfaces (APIs) do not hold any test oracle (test oracle problem). In order to mitigate this problem, metamorphic testing using appropriate metamorphic relations can be deployed in production phase. In the case of web service APIs, the response from an operation acts as the operands for the metamorphic test. The aim is to design and implement a software tool that can automate metamorphic testing of RESTful web APIs based on five major metamorphic relation output patterns (MROPs).KeywordsREST APIMetamorphic testingWeb API testingPost Release testingREST API testing tool

In recent years, more and more users use the handheld devices such as smartphone to access the Internet. Users can get their data from the Internet or update their status to the hot social networking Web sites (e.g., Twitter, Facebook and MySpace). These popular social networking Web sites usually provide the API (Application Programming Interface). Developers can use these APIs to rebuild a new Web site or a mobile phone application. The REST (Representational State Transfer) scheme is most famous architecture style to call these APIs. Despite there are already exist friendly mobile version Web sites. Users can use mobile Web browser to access these hot social networking Web sites or others. But there are many advantages in using mobile phone applications to access these Web sites through the RESTful APIs they provide. For example, mobile phone applications have fantastic UI and they can integrate with the mobile phone operation system such as open-source Android platform. Developers can develop a RESTful client application to avoid to download entire HTML or Javascript files that will cause many network traffics. But RESTful APIs also have overhead in transmission. In this thesis, we observed the overhead between mobile phone applications and RESTful APIs in low-bandwidth wireless network. We proposed a system architecture to reduce these transmission overheads. And then, speed up the response time and decrease the total transmission bytes.

Recent technological advancements in web-based geographic information systems have enabled access to satellite images on smart devices. The Representational State Transfer (REST) architecture overcomes difficulties that are associated with conventional data communications on the web, and the Web Graphics Library (WebGL) can be used as an alternative to web-based three-dimensional geographic visualization (3-D geovisualization) due to its efficient image processing capabilities. This paper describes a 3-D geovisualization system that was developed for satellite images on smart devices by integrating a spatial database management system (DBMS), a RESTful application programming interface (API), and WebGL. Spatiotemporal objects were constructed for time-series satellite images within a DBMS and a RESTful API was built for spatiotemporal queries to the time-series database so that the requested satellite data could be represented in 3-D on smart devices using WebGL. Satellite images that are represented in WebGL give a more realistic 3-D experience when they are combined with terrain data and provide for intuitive observations of the relationships between pixel values and associated geospatial conditions. This paper shows that a creative combination of existing technologies can be used to enhance and display satellite images on smart devices for 3-D geovisualization.

A primary concern in the design and development of a RESTful Application Programming Interfaces (APIs) is API security. A RESTful API provides data over the network using HTTP and must not violate any of its security properties. When APIs are designed, the functional and security properties are inextricably linked thus security requirements of an API cannot be treated as afterthoughts. We therefore propose an approach to specifying and verifying APIs functional and security requirements with the practical formal method SOFL (Structured-Object-oriented Formal Language). We convert an API specification written in an API description language into SOFL while expressing security requirements as constraints on the APIs functional requirements and dataflow between the API’s trust boundaries. The verification of the specifications can be carried out using specification-based conformance testing. We apply this approach to a model of an online banking API as a case study using Django REST Framework and analyze its results.

Mock is an object that replicates the behavior of a real object in a disciplined way and improves unit testing. Unit testing is a testing where each individual or component is tested. The purpose of unit testing is to validate each unit of designed software and allow to verify the generated code is working properly, regardless of its dependencies. A system under test has some external dependencies like APIs and creating a mock object based on that kind of dependencies would be efficient rather than generate a test case on the actual instance of the dependencies. A real working system such as banking, autonomous vehicles, online-supply chain businesses, and E-commerce platforms are heavily dependent on a server and facing difficulty while testing with a real server. Mock server helps in testing by simulating the behavior of a real server. Mocks could be used for testing and developing the front-end even when the back-end is not available. The aim of our research work is to propose a generic approach in which we propose a mock framework named MockRest for REST API in Java. The main reason to propose such kind of framework is to get a consistent response while real API is down at the moment by creating a mock of REST API as it allows the developer to stay constructive while the API is being implemented. Application Programming Interface (API) allows interaction between software programs, exchanges their information while REST is an architectural style, and applies to the design of API. A Web API that follows the standards of REST architectural style is a REST API. Based on the description of Web services by its interface, Mock simulates its behavior.

Hypermedia as the Engine of Application State (HATEOAS) is a principle that has been built upon the term hypermedia to refer to a constraint on the Representational State Transfer (REST) application architecture. This principle distinguishes REST from other application architectures, such as Simple Object Access Protocol in a way that client applications (e.g., a web app or a mobile app) need no prior knowledge for interacting with a REST-based Application Programming Interface (API) beyond a generic understanding of its hypermedia. Ion is an intuitive JavaScript Object Notation-based hypermedia type for REST, which can help software developers realize the principle of HATEOAS in their API design with ease. The goal of the work that is described in this paper has been to practically demonstrate the use of Ion in practice to have a self-documented REST API. For this purpose, a C# library has been implemented to demonstrate the use of Ion in having a REST API with self-documentation.

Web service-based application development has become a vital component of the modern in-formation technology ecosystem. The implementation of web services facilitates interoperability among diverse systems and platforms. REST API (REpresentational State Transfer Application Programming Interface) is one of the most popular architectures for creating efficient and scalable web services. This study examines the implementation of REST API in the development of web service-based applications. The case study focuses on the creation of a Web service-based Research Proposal Selection System. The REST API implementation method in this study adheres to the system development life cycle (SDLC) to ensure that the developed API meets business needs while being efficient, secure, and reliable. The analysis phase is conducted to gather both functional and non-functional REST API requirements. During the design phase, the REST API architecture is designed in detail, including how data will be transferred and processed, and how the API will interact with databases and other systems. Furthermore, in the implementation phase, the REST API is developed, ensuring that each endpoint operates correctly. In developing the Proposal Selection System, the implementation of web services integrates data from various existing sys-tems, including employee, academic, and research data. The system encompasses various features, such as proposal import, proposal mapping, proposal review, proposal assessment, proposal se-lection, and reporting. The research findings indicate that implementing the REST API simplifies the development of web service applications. The test results reveal that the average response time is relatively stable, measuring 31 ms without iterations and 29 ms with five iterations.

RESTful APIs (REpresentational State Transfer Application Programming Interfaces) are the most commonly used mechanism for biodiversity informatics databases to provide open access to their content. In its simplest form an API provides an interface based on the HTTP protocol whereby any client can perform an action on a data resource identified by a URL using an HTTP verb (GET, POST, PUT, DELETE) to specify the intended action. For example, a GET request to a particular URL (informally called an endpoint) will return data to the client, typically in JSON format, which the client converts to the format it needs. A client can either be custom written software or commonly used programs for data analysis such as R (programming language), Microsoft Excel (everybody’s favorite data management tool), OpenRefine, or business intelligence software. APIs are therefore a valuable mechanism for making biodiversity data FAIR (findable, accessible, interoperable, reusable). There is currently no standard specifying how RESTful APIs should be designed, resulting in a variety of URL and response data formats for different APIs. This presents a challenge for API users who are not technically proficient or familiar with programming if they have to work with many different and inconsistent data sources. We undertook a brief review of eight existing APIs that provide data about taxa to assess consistency and the extent to which the Darwin Core standard (Wieczorek et al. 2021) for data exchange is applied. We assessed each API based on aspects of URL construction and the format of the response data (Fig. 1). While only cursory and limited in scope, our survey suggests that consistency across APIs is low. For example, some APIs use nouns for their endpoints (e.g. ‘taxon’ or ‘species’), emphasising their content, whereas others use verbs (e.g. ‘search’), emphasising their functionality. Response data seldom use Darwin Core terms (two out of eight examples) and a wide range of terms can be used to represent the same concept (e.g. six different terms are used for dwc:scientificNameAuthorship). Terms that can be considered metadata for a response, such as pagination details, also vary considerably. Interestingly, the public interfaces for the majority of APIs assessed do not provide POST, PUT or DELETE endpoints that modify the database. POST is only used for providing more detailed request bodies to retrieve data than possible with GET. This indicates the primary use of APIs by biodiversity informatics platforms for data sharing. An API design guideline is a document that provides a set of rules or recommendations for how APIs should be designed in order to improve their consistency and useability. API design guidelines are typically created by particular organizations to standardize API development within the organization, or as a guideline for programmers using an organization’s software to build APIs (e.g., Microsoft and Google). The API Stylebook is an online resource that provides access to a wide range of existing design guidelines, and there is an abundance of other resources available online. This presentation will cover some of the general concepts of API design, demonstrate some examples of how existing APIs vary, and discuss potential options to encourage standardization. We hope our analysis, the available body of knowledge on API design, and the collective experience of the biodiversity informatics community working with APIs may help answer the question “Does TDWG need an API design guideline?”

Casing design and the associated load assumptions have evolved considerably over the last 30 years. The objective of this paper is to trace the history, evolution and future of casing design by means of the type of load cases and the assumptions made for them as it evolved from the early 1960's to the modern load case requirements for wells drilled in the 2020's. The vast majority of tubular failures in oil & gas wells are not attributable to computational errors in calculating design loads, but rather are due to a shortfall in considering the appropriate load scenarios. One common shortfall includes making incorrect or oversimplified assumptions for the initial and final temperature and pressure conditions. There is no industry standard for casing or tubing design loads, but there is an industry accepted standard process for the calculation of the stress on tubulars once the load cases are determined. Each operating company may use a different set of load assumptions depending on the well type and risk assessment. This work also keeps in view the major computational tools used during each step change of the casing design evolution: slide rule/nomographs, HP 41C calculators, PC DOS and Windows programs, and the latest Cloud-Native paradigm with REST API's within a microservices architecture. A REST API (also known as RESTful API) is an Application Programming Interface (API) that conforms to the constraints of Representational State Transfer (REST) architectural style commonly used in current Cloud computing technology. The scope will also include ongoing research and development to address shortcomings of previous load case assumptions and calculations for extended reach and HPHT wells, closely spaced wells, and geothermal wells. Modern wells and modern casing design load cases are in a constant state of evolution and casing failures will occur unless engineers and their tools also evolve.

JASPAR is a widely used open-access database of curated, non-redundant transcription factor binding profiles. Currently, data from JASPAR can be retrieved as flat files or by using programming language-specific interfaces. Here, we present a programming language-independent application programming interface (API) to access JASPAR data using the Representational State Transfer (REST) architecture. The REST API enables programmatic access to JASPAR by most programming languages and returns data in eight widely used formats. Several endpoints are available to access the data and an endpoint is available to infer the TF binding profile(s) likely bound by a given DNA binding domain protein sequence. Additionally, it provides an interactive browsable interface for bioinformatics tool developers. This REST API is implemented in Python using the Django REST Framework. It is accessible at http://jaspar.genereg.net/api/ and the source code is freely available at https://bitbucket.org/CBGR/jaspar under GPL v3 license. aziz.khan@ncmm.uio.no or anthony.mathelier@ncmm.uio.no. Supplementary data are available at Bioinformatics online.

Modern web services widely provide RESTful APIs for clients to access their functionality programmatically. Fuzzing is an emerging technique for ensuring the reliability of RESTful APIs. However, the existing RESTful API fuzzers repeatedly generate invalid requests due to unawareness of errors in the invalid tested requests and lack of effective strategy to generate legal value for the incorrect parameters. Such limitations severely hinder the fuzzing performance. In this paper, we propose DynER, a new test case generation method guided by dynamic error responses during fuzzing. DynER designs two strategies of parameter value generation for purposefully revising the incorrect parameters of invalid tested requests to generate new test requests. The strategies are, respectively, based on prompting Large Language Model (LLM) to understand the semantics information in error responses and actively accessing API-related resources. We apply DynER to the state-of-the-art fuzzer RESTler and implement DynER-RESTler. DynER-RESTler outperforms foREST on two real-world RESTful services, WordPress and GitLab with a 41.21% and 26.33% higher average pass rate for test requests and a 12.50% and 22.80% higher average number of unique request types successfully tested, respectively. The experimental results demonstrate that DynER significantly improves the effectiveness of test cases and fuzzing performance. Additionally, DynER-RESTler finds three new bugs.

The Web of Things is an active research field which aims at promoting the easy access and handling of smart things' digital representations through the adoption of Web standards and technologies. While huge research and development efforts have been spent on lower level networks and software technologies, it has been recognized that little experience exists instead in modeling and building applications for the Web of Things. Although several works have proposed Representational State Transfer (REST) inspired approaches for the Web of Things, a main limitation is that poor support is provided to web developers for speeding up the development of Web of Things applications while taking full advantage of REST benefits. In this paper, we propose a framework which supports developers in modeling smart things as web resources, exposing them through RESTful Application Programming Interfaces (APIs) and developing applications on top of them. The framework consists of a Web Resource information model, a middleware, and tools for developing and publishing smart things' digital representations on the Web. We discuss the framework compliance with REST guidelines and its major implementation choices. Finally, we report on our test activities carried out within the SmartSantander European Project to evaluate the use and proficiency of our framework in a smart city scenario.

The much-anticipated revolution of the “Internet of things” (IoT) is expected to generate one trillion internet devices within the next 15 years, mostly in the form of simple wireless sensor devices. While this revolution promises to transform silicon markets and drive a number of disruptive changes in society, it is also the case that the protocols, complexity, and security issues of extremely large dynamic, co-mingled networks is still poorly understood. Furthermore, embedded system developers, to include military and aerospace users, have largely ignored the potential (good and bound) of the cloudlike, possibly intermingling networks having variable structure to how future systems might be engineered. In this paper, we consider a new interpretation of IoT inspired modular architecture strategies involving the representational state transfer (REST) model, in which dynamic networks with variable structure employ stateless application programming interface (API) concepts. The power of the method, which extends concepts originally developed for space plug-and-play avionics, is that it allows for the fluid co-mingling of hardware and software in networks whose structure can overlap and evolve. Paradoxically, these systems may have the most stringent determinism and fault-tolerant needs. In this paper we review how RESTful APIs can potentially be used to design, create, test, and deploy systems rapidly while addressing security and referential integrity even when the nodes of many systems might physically co-mingle. We will also explore ways to take advantage of the RESTful paradigm for fault tolerance and what extensions might be necessary to deal with high-performance and determinism.

In the rapidly evolving digital era, Application Programming Interfaces (APIs) have emerged as the cornerstone of modern software development, enabling seamless communication and data exchange between disparate systems. Optimizing API project efficiency is paramount for organizations aiming to stay competitive and agile in response to market demands. This paper explores strategies for enhancing API efficiency through agile configurations, advanced design patterns, and comprehensive testing methodologies. We delve into the significance of decoupling configurations to achieve agile adaptability, discuss various API design paradigms like RESTful APIs and GraphQL, and examine their specific use cases and benefits. Additionally, we emphasize the importance of robust testing and security practices, highlighting industry-standard tools and technologies that facilitate these processes. Real-world case studies are presented to illustrate practical implementations, and the tangible improvements achieved. By integrating these advanced strategies, organizations can enhance their API performance, scalability, and maintainability, thereby delivering superior value to users and stakeholders in an increasingly interconnected world. Keywords: API efficiency, agile adaptability, decoupling configurations, RESTful API, GraphQL, API testing, microservices, API gateway, performance optimization, configuration management, API security, authentication, automated testing, real-world case studies

In this chapter, you’ll learn how to send data to an IoT server using a RESTful API. A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST, and DELETE data. The ThingSpeak IoT platform enables clients to update and receive updates from channel feeds through the ThingSpeak RESTful API.