Results indicate that organizing specifications according to version and content type can be an effective design choice for RAG-based REST API misuse repair.
Abstract
Many Internet of Things (IoT) services provide Representational State Transfer (REST) APIs, which require client developers to implement applications that conform to the corresponding API specifications. When client programs contain API misuse, developers debug them based on error responses. However, such responses are often insufficient for identifying the root cause, requiring developers to repeatedly communicate with the server. Retrieval-Augmented Generation (RAG) is a promising approach for providing large language models (LLMs) with external knowledge. However, in automated repair of REST API misuses, it remains unclear how specifications should be stored in a RAG database. This study evaluates how different configurations for organizing API specifications affect RAG-based repair of REST API misuse. We constructed 11 RAG configurations with different database structures and compared their repair rates with a baseline method. For evaluation, we used REST API misuse cases collected from real-world repositories. The results show that, in the studied datasets, the baseline method achieved a repair rate of 54.3%, whereas a RAG-based method using four databases achieved a maximum repair rate of 88.6%. These results indicate that organizing specifications according to version and content type can be an effective design choice for RAG-based REST API misuse repair.
RESTCov is a lightweight tool that computes structural REST API coverage from an OpenAPI specification and observed HTTP request/response logs, reporting coverage across paths, operations, parameters, media types, status codes, and status classes.
Modern software development heavily relies on reusing third-party and internal Application Programming Interfaces (APIs). However, API misuses occur frequently, leading to program crashes, security vulnerabilities, and other unexpected behaviors. To detect API misuse, many existing approaches mine API usage patterns fr...
Yang-Sen Wang, Yi-Zhou Chen, Zhi-Hao Gong et al.· ACM Transactions on Software...· 0 citations
Smart contracts are at risk of significant financial losses due to vulnerabilities in their program logic. To mitigate such damages, various automated program repair tools have been proposed. However, existing tools, especially those based on Large Language Models (LLMs), may introduce unintended changes to the origina...
Chihiro Kado, Tatsuhiro Tsuchiya· Proceedings of the 7th Inter...· 0 citations
REST APIs are widely used on the web for client-server communications. As REST is based on HTTP, server responses contain status codes to indicate the outcome of requests (e.g., 200 OK for a success and 404 Not Found for an unavailable resource). While HTTP status codes are standardized, their semantics are not enforce...
Alix Decrop, Andrea Arcuri, Mike Papadakis et al.· 0 citations
This study evaluates the effectiveness of multiple state-of-the-art LLMs in generating executable REST API test cases from OpenAPI documentation and proposes a generalized prompt template that balances reasoning quality and practical usability for exploratory API testing.
Infrastructure as Code (IaC) enables the automated provisioning of cloud infrastructures, yet syntactically valid configurations may remain unsuitable for the applications they support. Addressing such issues requires knowledge of both the infrastructure and its runtime behavior. We introduce POLIAC, an LLM-based frame...
Haitam El Hayani, Jolan Philippe, Stéphanie Challita· Proceedings of the 3rd Inter...· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.