Remove dynmaic analysis

README.md

@@ -60,15 +60,9 @@ This produces the following output:
 ```cli
 java -jar build/libs/rest-ruler.jar -p https://api.apis.guru/v2/specs/circleci.com/v1/openapi.yaml
 
------------------INFO ANALYSIS----------------
+----------------START ANALYSIS----------------
 -----------------------------------------------
 
-Besides the static analysis there is the dynamic analysis for which the credentials for the openapi definition need to be provided. These are not stored unless you allow it. No changes will be made to resources nor are they saved. 
-If you want to do the dynamic analysis, enter yes or y, if you do not want to do it, enter any other key.
-[yes/no]
-n
-----------------------------------------------
-
 Begin with the analysis of the file from: https://api.apis.guru/v2/specs/circleci.com/v1/openapi.yaml
 
 ----------------------------------------------

docs/rules/README.md

@@ -8,10 +8,9 @@
 - [Sources](#sources)
 
 ## Documenting implemented rule
-The rules implemented in the CLI are from Masse's book [1]. Additional informations about this rule are from Kotstein and Bogner [2]. Rules were selected by importance (categorization by Delphi study) --> first, implementation of high importance, ... Then add rule properties (difficulty of implementation, severity, type of analysis, software quality attributes , etc.)
+The rules implemented in the CLI are from Masse's book [1]. Additional informations about this rule are from Kotstein and Bogner [2]. Rules were selected by importance (categorization by Delphi study) --> first, implementation of high importance, ... Then add rule properties (difficulty of implementation, severity, software quality attributes , etc.)
 * **Category** of the rule (from Kotstein and Bogner [2])
 * Rules are categorized into three categories regarding **difficulty of implementation**: *easy, medium, and difficult*. 
-* Matching the implementation idea, add the **type of analysis**: *static and/or dynamic*.
 * **Software quality attributes** linked to rules are from Kotstein and Bogner. Quality attributes are: *functional suitability, performance efficiency, compatibility, usability, reliability, maintainability and portability*. 
 * Categorize the rules according to the **severity**: *Warning* (may be), *Error* (should be), and *Critical* (must be). The severity indicates the urgency of a violation to be fixed. Naming conventions were inspired by IBM [3]. The tag *Critical* is derived from Massé's definition of the rule, in which *"must be"* is used as a phrase. It means that there is a critical condition with this violation and must be fixed immediately. An *Error* is assigned if *"should be"* is used as a phrase in the rule definition and means that there is an error condition with the violation, which should be removed. Lastly, the tag *Warning* is used when *"may be"* is used as a phrase and indicates a possible problem that may be fixed sooner or later.
 * Add **implementation details** (_what is checked, what is not checked, future implementations_)
@@ -35,25 +34,25 @@ with *"https"* being the scheme, *"example.com:8080"* the authority, *"shelter/a
 For the implementation of rules related to the URI, we work on the *"path"*-portion of the URI. In an OpenAPI definition of an API, the path portion can be found in the *"paths"*-segment. Each path in the *"paths"* segment may optionally contain a list of parameter definitions for both path variables as also query parameters next to the required definition of the path. It may also contain request bodies and response definitions for numerous HTTP response codes. In these responses, a detailed description of what kind of response object, such as their data type, will be received for each HTTP response code.
 
 ### List of implemented rules
-Documentation about the rules can be found in the [folder](./Implemented-Rules).
-
-* [Forward slash separator (/) must be used to indicate a hierarchical relationship](./Implemented-Rules/Forward-slash-separator-must-be-used-to-indicate-a-hierarchical-relationship.md)
-* [A trailing forward slash (/) should not be included in URIs](./Implemented-Rules/A-trailing-foward-slash-should-not-be-included-in-URIs.md)
-* [GET and POST must not be used to tunnel other request methods](./Implemented-Rules/GET-and-POST-must-not-be-used-to-tunnel-other-request-methods.md) 
-* [GET must be used to retrieve a representation of a resource](./Implemented-Rules/GET-must-be-used-to-retrieve-a-representation-of-a-resource.md)
-* [File extensions should not be included in URIs](./Implemented-Rules/File-extensions-should-not-be-included-in-URIs.md)
-* [Content-Type must be used](./Implemented-Rules/Content-Type-must-be-used.md)
-* [CRUD function names should not be used in URIs](./Implemented-Rules/CRUD-function-names-should-not-be-used-in-URIs.md)
-* [Underscores (_) should not be used in URI](./Implemented-Rules/Underscores-(_)-should-not-be-used-in-URI.md)
-* [401 (Unauthorized) must be used when there is a problem with the client’s credentials](./Implemented-Rules/401-(Unauthorized)-must-be-used-when-there-is-a-problem-with-the-client's-credentials.md)
-* [Hyphens (-) should be used to improve the readability of URIs](./Implemented-Rules/Hyphens-(-)-should-be-used-to-improve-the-readability-of-URIs.md)
-* [Lowercase letters should be preferred in URI paths](./Implemented-Rules/Lowercase-letters-should-be-preferred-in-URI-paths.md)
-* [A plural noun should be used for collection or store names](./Implemented-Rules/A-plural-noun-should-be-used-for-collection-or-store-names.md)
-* [A singular noun should be used for document names](./Implemented-Rules/A-singular-noun-should-be-used-for-document-names.md)
-* [A verb or verb phrase should be used for controller names](./Implemented-Rules/A-verb-or-verb-phrase-should-be-used-for-controller-names.md)
+Documentation about the rules can be found in the [folder](./implemented-rules).
+
+* [Forward slash separator (/) must be used to indicate a hierarchical relationship](./implemented-rules/Forward-slash-separator-must-be-used-to-indicate-a-hierarchical-relationship.md)
+* [A trailing forward slash (/) should not be included in URIs](./implemented-rules/A-trailing-foward-slash-should-not-be-included-in-URIs.md)
+* [GET and POST must not be used to tunnel other request methods](./implemented-rules/GET-and-POST-must-not-be-used-to-tunnel-other-request-methods.md) 
+* [GET must be used to retrieve a representation of a resource](./implemented-rules/GET-must-be-used-to-retrieve-a-representation-of-a-resource.md)
+* [File extensions should not be included in URIs](./implemented-rules/File-extensions-should-not-be-included-in-URIs.md)
+* [Content-Type must be used](./implemented-rules/Content-Type-must-be-used.md)
+* [CRUD function names should not be used in URIs](./implemented-rules/CRUD-function-names-should-not-be-used-in-URIs.md)
+* [Underscores (_) should not be used in URI](./implemented-rules/Underscores-(_)-should-not-be-used-in-URI.md)
+* [401 (Unauthorized) must be used when there is a problem with the client's credentials](./implemented-rules/401-(Unauthorized)-must-be-used-when-there-is-a-problem-with-the-client's-credentials.md)
+* [Hyphens (-) should be used to improve the readability of URIs](./implemented-rules/Hyphens-(-)-should-be-used-to-improve-the-readability-of-URIs.md)
+* [Lowercase letters should be preferred in URI paths](./implemented-rules/Lowercase-letters-should-be-preferred-in-URI-paths.md)
+* [A plural noun should be used for collection or store names](./implemented-rules/A-plural-noun-should-be-used-for-collection-or-store-names.md)
+* [A singular noun should be used for document names](./implemented-rules/A-singular-noun-should-be-used-for-document-names.md)
+* [A verb or verb phrase should be used for controller names](./implemented-rules/A-verb-or-verb-phrase-should-be-used-for-controller-names.md)
 
 ### Rule implementation and extension
-For each rule, a single Java class is created, which can be found in in this [dir](../../src/main/java/cli/rule/rules). It is just as easy to implement a new rule. For implementing a new rule, it is merely necessary to create a Java class in the folder just mentioned, which implements the [`IRestRule`](../../src/main/java/cli/rule/IRestRule.java) interface. Then, a constructor with an `isActive` boolean is needed. Now the rule is automatically recognized and listed in the CLI. This is the minimum that needs to be done to implement a new static rule. However, for a dynamic analysis, it must first be checked whether it is requested by the user. Therefore, it is necessary to check the attributes `dynamicAnalysis` (boolean) and `securitySchemas` of the [calling class](../../src/main/java/cli/analyzer/RestAnalyzer.java). This is possible because they are `public static` in the Java class. The latter attribute is a list of user-specified security schemes for the API, either a `bearer` token, `basic` authentication, or an `api-key`. Based on this, the necessary information for a dynamic analysis is available and requests can be sent to the API.
+For each rule, a single Java class is created, which can be found in in this [dir](../../src/main/java/cli/rule/rules). It is just as easy to implement a new rule. For implementing a new rule, it is merely necessary to create a Java class in the folder just mentioned, which implements the [`IRestRule`](../../src/main/java/cli/rule/IRestRule.java) interface. Then, a constructor with an `isActive` boolean is needed. Now the rule is automatically recognized and listed in the CLI. This is the minimum that needs to be done to implement a new rule. 
 
 For a better user experience, the progress bar can be called from the [output class](../../src/main/java/cli/utility/Output.java).
 

docs/rules/implemented-rules/401-(Unauthorized)-must-be-used-when-there-is-a-problem-with-the-client's-credentials.md

@@ -1,41 +1,40 @@
 # 401 ("Unauthorized") must be used when there is a problem with the client's credentials
+
 ## Category
+
 URIs
 
 ## Importance, severity, difficulty
+
 * Importance: high
 * Severity: critical
 * Difficulty to implement the rule: easy
 
 ## Quality Attribute
+
 * Usability
 * Compatibility
 * Maintainability
 
 ## Rule Description
+
 Description from Massé [1].
 
 "A 401 error response indicates that the client tried to operate on a protected resource without providing the proper authorization. It may have provided the wrong credentials or none at all."
 
 ## Implemented
+
 * Y
 
 ## Implementation Details (Issue #31)
+
 ### What is checked
-#### Static analysis
 * When the security is globally defined all operations for the path need the 401 response
 * When the security is locally defined all local operations for the path need the 401 response
 
-#### Dynamic analysis
-For GET operations that statically had no violation and no 401 response defined, a request is made with manipulated pw. If no 401 is received as a response, there is a rule violation.
-
-### What is not checked
-* POST, PUT, DELETE, ... are not checked *<sup>1</sup>
-* If a wrong status code (not the 401 response) is used even though an auth is required *<sup>2</sup>
-
-*<sup>1</sup> Problems: e.g. POST request does not have an auth --> resources are updated
+### Future work
 
-*<sup>2</sup> Implementation ideas: Use the response messages and train an ai if the message contains something like: unauthorized, wrong auth, not auth, ...
+* --
 
 ## Source
 

docs/rules/implemented-rules/A-plural-noun-should-be-used-for-collection-or-store-names.md

@@ -19,8 +19,7 @@ URIs
 
 Description from Massé [1].
 
-"A URI representing a document resource should be named with a singular noun or
-noun phrase path segment."
+"A URI representing a document resource should be named with a singular noun or noun phrase path segment."
 
 ## Implemented
 
@@ -30,19 +29,19 @@ noun phrase path segment."
 
 ### What is checked
 
-* Currently, static implementation only
 * Check every pathSegment which are generated from the split of the path using the "/" as delimiter. If the pathSegment is a
   collection or store name, it should be plural. If it is not plural, it is a violation.
 * The structure of a path is normally as follows: singular/plural/singular.. or plural/singular/plural.. . If we have a path with singular/singular then we have a violation.
-* For each pathSegment is being checked if the word is singular or plural. For this taks we are using OpenNLP, an Apache library, which is able to detect if a word is singular or plural.
+* For each pathSegment is being checked if the word is singular or plural. For this task, we are using OpenNLP, an Apache library, which is able to detect if a word is singular or plural.
 
 ### What is not checked
 
 * The semantic of rule is not checked, only the syntax following the defined schema.
+
 ### Future work
 
-* Dynamic analysis will check the parameter input if it is plural or singular
 * If a path segment is composed of more than one word, then we need to only take the last one into consideration
+
 ## Source
 
 [1] https://www.oreilly.com/library/view/rest-api-design/9781449317904/

docs/rules/implemented-rules/A-singular-noun-should-be-used-for-document-names.md

@@ -19,8 +19,7 @@ URIs
 
 Description from Massé [1].
 
-"A URI representing a document resource should be named with a singular noun or
-noun phrase path segment."
+"A URI representing a document resource should be named with a singular noun or noun phrase path segment."
 
 ## Implemented
 
@@ -30,18 +29,19 @@ noun phrase path segment."
 
 ### What is checked
 
-* Currently, static implementation only
 * Check every pathSegment which are generated from the split of the path using the "/" as delimiter. If the pathSegment is a
   document name, it should be singular. If it is not singular, it is a violation. 
 * The structure of a path is normally as follows: singular/plural/singular.. or plural/singular/plural.. . If we have a path with plural/plural then we have a violation.
-* For each pathSegment is being checked if the word is singular or plural. For this taks we are using OpenNLP, an Apache library, which is able to detect if a word is singular or plural.
+* For each pathSegment is being checked if the word is singular or plural. For this tak, we are using OpenNLP, an Apache library, which is able to detect if a word is singular or plural.
+
 ### What is not checked
 
-* * The semantic of rule is not checked, only the syntax following the defined schema.
+* The semantic of rule is not checked, only the syntax following the defined schema.
+
 ### Future work
 
-* Dynamic analysis will check the parameter input if it is plural or singular
 * If a path segment is composed of more than one word, then we need to only take the last one into consideration
+
 ## Source
 
 [1] https://www.oreilly.com/library/view/rest-api-design/9781449317904/

docs/rules/implemented-rules/A-trailing-foward-slash-should-not-be-included-in-URIs.md

@@ -1,26 +1,42 @@
-# Rule
-A trailing forward slash (/) should not be included in URIs
+# A trailing forward slash (/) should not be included in URIs
+
 ## Category
+
 URIs
+
 ## Importance, severity, difficulty
+
 * medium
 * error severity
 * easy difficulty
+* 
 ## Quality Attribute
+
 * Maintainability
 
 ## Rule Description
-As the last character within a URI’s path, a forward slash (/) adds no semantic value and may cause confusion. REST APIs should not expect a trailing slash and should not include them in the links that they provide to clients.[1].
+As the last character within a URI's path, a forward slash (/) adds no semantic value and may cause confusion. REST APIs should not expect a trailing slash and should not include them in the links that they provide to clients.[1].
 The way we understand this rule is that no forward slash (/) is to be included from the end of a path segment in a URI. To enforce this rule, we check each path segment in an OpenAPI definition if it ends with a forward slash (/) and in the case of a trailing forward slash (/), throw a violation.
+
 ## Implemented
+
 * Y
+
 ## Implementation Details
-This is a rule that is examined statically. 
+
+The last character of each URI paths is checked.
+
 ### What is checked:
+
 - Checks if a path segement contains a trailing foward slash (/)
+
 ### What is not checked:
-None
+
+* --
+
 ### Future work
-None
+
+* --
+
 ## Source
 [1] https://www.oreilly.com/library/view/rest-api-design/9781449317904/

docs/rules/implemented-rules/A-verb-or-verb-phrase-should-be-used-for-controller-names.md

@@ -19,8 +19,7 @@ URIs
 
 Description from Massé [1].
 
-"Like a computer program’s function, a URI identifying a controller resource should be
-named to indicate its action."
+"Like a computer program's function, a URI identifying a controller resource should be named to indicate its action."
 
 ## Implemented
 
@@ -30,16 +29,16 @@ named to indicate its action."
 
 ### What is checked
 
-* This rule is implemented in a static way.
 * Split every path in path segments and analyze the last one. If the last path segment contains a verb as first word, and the request is not of type GET or POST then the rule is violated. 
 * The rule requires to use a verb to indicate controller actions. A controller can only be of type GET or POST.
+
 ### What is not checked
 
 * The semantic of rule is not checked, only the syntax following the defined schema.
+
 ### Future work
 
-* Use the description of each path to gather more information and to perform a better decision on suggestion to the user if the last path segment could
-be used as controller. For example, if the last path segment is a noun, then the rule could suggest using a verb or verb phrase to indicate the action.
+* Use the description of each path to gather more information and to perform a better decision on suggestion to the user if the last path segment could be used as controller. For example, if the last path segment is a noun, then the rule could suggest using a verb or verb phrase to indicate the action.
 
 ## Source
 

docs/rules/implemented-rules/CRUD-function-names-should-not-be-used-in-URIs.md

@@ -19,9 +19,7 @@ URIs
 
 Description from Massé [1].
 
-"URIs should not be used to indicate that a CRUD§ function is performed. URIs should
-be used to uniquely identify resources [...]" and the "[...] HTTP request methods
-should be used to indicate which CRUD function is performed."
+"URIs should not be used to indicate that a CRUD§ function is performed. URIs should be used to uniquely identify resources [...]" and the "[...] HTTP request methods should be used to indicate which CRUD function is performed."
 
 "For example, this API interaction design is preferred:
 
@@ -32,7 +30,7 @@ The following anti-patterns exemplify what not to do:
 * GET /deleteUser?id=1234
 * GET /deleteUser/1234
 * DELETE /deleteUser/1234
-* POST /users/1234/delete
+* POST /users/1234/delete"
 
 ## Implemented
 
@@ -42,21 +40,20 @@ The following anti-patterns exemplify what not to do:
 
 ### What is checked
 
-* Currently, static implementation only
 * Checks every path (server paths included) if it contains CRUD operation keywords and returns a list of violations
 * Individual segments are checked if they have a crud operation as substring (target includes get) --> there is no violation
 * Keywords that are currently checked: "get", "post", "delete", "put", "create", "read", "update", "patch", "insert", "select", "fetch", "purge", "retrieve", "add"
 
 ### What is not checked
 
-* The parameters in curly brackets are excluded from the path and are therefore currently not checked in a dynamic fashion
+* The parameters in curly brackets are excluded from the path and are therefore currently not checked
 * If more than these previously defined words are to be considered CRUD violations, perform the following steps:
    1. Add the appropriate words to the attribute `CRUD_OPERATIONS` in the `./src/main/java/cli/rule/rules/CRUDRule.java` 
    2. Mine the words that have the appropriate words as substring from `./src/main/java/cli/docs/wordninja_words.txt` and add them to the list `./src/main/java/cli/docs/CRUD_words.txt` (Exclude similar words to still detect the violation; e.g. "gets" from "get")
 
 ### Future work
 
-* Dynamic analysis will check the parameter input if it contains CRUD operation keywords
+* --
 
 ## Source