@@ -4,11 +4,11 @@ Also, it might be a meaningful approach to raise the security and quality in web
% example with [2]
One kind of testing such architectures is to validate REST interfaces and check if there are errors in them. \\
In the last years, the OpenAPI Specification has become the common way to document the communication endpoints and exchanged data structures [1]. This is useful to test REST interfaces, because it enables the black-box testing approach.
In the last years, the OpenAPI Specification\footnote{\url{https://swagger.io/specification}} has become the common way to document the communication endpoints and exchanged data structures. This is useful to test REST interfaces, because it enables the black-box testing approach.
OpenAPI specifications are described as JSON or YAML documents and are defined by a semi-formal specification describing permitted and required elements as well as their semantics. While there is no formal definition of the full OpenAPI language, a meta-schema exists for the JSON Schema parts of the language.
% abstract
This paper investigates how such specifications can be used to test interfaces described by them. Since these specifications itself are tree-shaped, the investigation focuses on a grammar-based analysis approach, reference attribute grammars (RAGs).
This paper investigates how such specifications can be used to test interfaces described by them. Since these specifications are tree-shaped, the investigation focuses on a grammar-based analysis approach, reference attribute grammars (RAGs).
This paper also compares already presented REST API automatic testing approaches and examines whether these can also be implemented in RAGs, whether this implementation makes sense at all and whether RAG improves at implementing REST API automated testing. \\
To sum up, following three questions are formulated as research questions:
OpenAPI defines a parameter in an operation in four types, Query, Path, Header and Cookie$^{5}$. \footnote{this is described at \url{http://test.com}} In this work, only Query and Path parameters are considered to research the functionality of the Fuzzing prototype in RAG. These parameters are clearly describable in String values and also comfortably testable, because they target only variable URIs. \\
For the experiments, the OpenAPI document of a Pet Store is mainly used$^{6}$. Additionally, only GET and POST operations are tested to research basic functionality firstly.
OpenAPI defines a parameter in an operation in four types, Query, Path, Header and Cookie\footnote{\url{https://swagger.io/docs/specification/describing-parameters}}. In this work, only Query and Path parameters are considered to research the functionality of the Fuzzing prototype in RAG. These parameters are clearly describable in String values and also comfortably testable, because they target only variable URIs. \\
For the experiments, the OpenAPI document of a Pet Store is mainly used\footnote{\url{https://petstore.swagger.io}}. Additionally, only GET and POST operations are tested to research basic functionality firstly.
% Process
The main code at random testing is following:
...
...
@@ -23,14 +23,5 @@ with the generated URI (Line 9).
% Result
Besides operations with requirements of request bodies, results of this implementation made possible to observe that parameters based on the specification were successfully randomized and they produced documented status codes in their operations. For future work, constraints of schema (minItems, maxItems, minLengths, maxLengths, etc.) can be completely extended. In this approach, the generator considers only the existence of enums.
