Logius-standaarden · sanderke · Jan 8, 2025 · Apr 23, 2024 · Apr 25, 2024 · Sep 2, 2024
diff --git a/DesignRules.md b/DesignRules.md
@@ -104,16 +104,11 @@ A resource describing a single thing is called a [=singular resource=]. Resource
       </dd>
       <dt>Implications</dt>
       <dd>
-         This rule is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The source code of the technical test can be found <a href="https://gitlab.com/commonground/don/adr-validator/-/blob/v0.5.0/pkg/rulesets/core/rules.go#L203">here</a>. The specific tests are published in the [[ADR-Validator]] repository.
-      </dd>      
+         This rule can be tested automatically and an example of the test is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The specific tests are published in the [[ADR-Validator]] repository.
+      </dd>
       <dt>How to test</dt>
       <dd>
-         <ul>
-            <li> Step 1: The API MUST meet the prerequisets to be tested. These include that an OAS file is publicly available, parsable, all $refs are resolvable and paths are defined.</li>
-            <li> Step 2: Check if paths are present in the OpenAPI Specification.</li>
-            <li> Step 3: Loop al paths and check if it ends with a slash ("/").</li>
-            <li> Step 4: Check all paths with a get request and without parameters. They SHOULD resolve in HTTP 404.</li>
-         </ul>
+         Loop all resource paths in the OpenAPI Description and check that no resources paths end with a forward slash (<code>/</code>).
       </dd>
    </dl>
 </div>
@@ -199,7 +194,7 @@ Although the REST architectural style does not impose a specific protocol, REST
       </dd>
       <dt>Implications</dt>
       <dd>
-         This rule is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The source code of the technical test can be found <a href="https://gitlab.com/commonground/don/adr-validator/-/blob/v0.5.0/pkg/rulesets/core/rules.go#L60">here</a>. The specific testscripts are published in the [[ADR-Validator]] repository.
+         This rule can be tested automatically and an example of the test is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The specific testscripts are published in the [[ADR-Validator]] repository.
       </dd>
    <div class="example">The following table shows some examples of the use of standard HTTP methods:
       <table>
@@ -244,27 +239,9 @@ Although the REST architectural style does not impose a specific protocol, REST
   In addition to the standard HTTP methods, a server may support other optional methods as well, e.g. <code>PROPFIND</code>, <code>COPY</code>, <code>PURGE</code>, <code>VIEW</code>, <code>LINK</code>, <code>UNLINK</code>, <code>LOCK</code>, <code>UNLOCK</code>, etc.<br>
   If an optional HTTP request method is sent to a server and the server does not support that HTTP method for the target resource, an HTTP status code <code>405 Method Not Allowed</code> shall be returned and a list of allowed methods for the target resource shall be provided in the <code>Allow</code> header in the response as stated in <a href="https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.5">RFC 7231 6.5.5</a>.</p>
       <dt>How to test</dt>
-      <p>Test case 1:</p>
       <dd>
-         <ul>
-            <li> Step 1: The API MUST meet the prerequisites to be tested. These include that an OAS file is publicly available, parsable, all $refs are resolvable and paths are defined.</li>
-            <li> Step 2: Send an HTTP GET or HEAD request to any of the endpoints with a definition of a GET operation mentioned in the OAS file. The server MUST respond with a HTTP status code other than <code>405 Method Not Allowed</code>.</li>
-        </ul>
-      </dd>
-      <p>Test case 2:</p>
-      <dd>
-         <ul>
-            <li> Step 1: The API MUST meet the prerequisites to be tested. These include that an OAS file is publicly available, parsable, all $refs are resolvable, and paths are defined.</li>
-            <li> Step 2: Send a request to the API with an optional HTTP method that is supported by the API. The server MUST respond with an HTTP status code other than <code>405 Method Not Allowed</code>.</li>
-      </ul>
+         The OpenAPI Description MUST NOT include non standard HTTP methods for retrieving or manipulating resources.
       </dd>
-     <p>Test case 3:</p>
-      <dd>
-         <ul>
-            <li> Step 1: The API MUST meet the prerequisites to be tested. These include that an OAS file is publicly available, parsable, all $refs are resolvable, and paths are defined.</li>
-            <li> Step 2: Send a request to the API with an optional HTTP method that is not supported by the API. The server MUST respond with an HTTP status code <code>405 Method Not Allowed</code>. The response MUST contain an <code>Allow</code> header with a list of supported methods for the target resource.</li>
-      </ul>
-      </dd>   
    </dl>
 </div>
 
@@ -444,7 +421,7 @@ An API is as good as the accompanying documentation. The documentation has to be
       </dd>
       <dt>Implications</dt>
       <dd>
-         This rule is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The source code of the technical test can be found <a href="https://gitlab.com/commonground/don/adr-validator/-/blob/v0.5.0/pkg/rulesets/core/rules.go#L123">here</a>. The specific tests are published in the [[ADR-Validator]] repository.
+         This rule can be tested automatically and an example of the test is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The specific tests are published in the [[ADR-Validator]] repository.
       </dd>
       <dt>How to test</dt>
       <dd>
@@ -496,14 +473,14 @@ An API is as good as the accompanying documentation. The documentation has to be
       </dd>
       <dt>Implications</dt>
       <dd>
-         This rule is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The source code of the technical test can be found <a href="https://gitlab.com/commonground/don/adr-validator/-/blob/v0.5.0/pkg/rulesets/core/rules.go#L257">here</a>. The specific tests are published in the [[ADR-Validator]] repository.
+         This rule can be tested automatically and an example of the test is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The specific tests are published in the [[ADR-Validator]] repository.
       </dd>
       <dt>How to test</dt>
       <dd>
          <ul>
             <li> Step 1: The API MUST meet the prerequisets to be tested. These include that an OAS file (openapi.json) is publicly available, parsable, all $refs are resolvable and paths are defined.</li>
             <li> Step 2: The openapi.yaml MAY be available. If available it MUST contain yaml, be readable and parsable.</li>
-            <li> Step 3: The openapi.yaml MUST contain the same OpenAPI Specification as the openapi.json.</li>
+            <li> Step 3: The openapi.yaml MUST contain the same OpenAPI Description as the openapi.json.</li>
             <li> Step 4: The CORS header Access-Control-Allow-Origin MUST allow all origins.</li>
          </ul>
       </dd>
@@ -573,13 +550,13 @@ Changes in APIs are inevitable. APIs should therefore always be versioned, facil
       </dd>
       <dt>Implications</dt>
       <dd>
-         This rule is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The source code of the technical test can be found <a href="https://gitlab.com/commonground/don/adr-validator/-/blob/v0.5.0/pkg/rulesets/core/rules.go#L164">here</a>. The specific tests are published in the [[ADR-Validator]] repository.
+         This rule can be tested automatically and an example of the test is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The specific tests are published in the [[ADR-Validator]] repository.
       </dd>
       <dt>How to test</dt>
       <dd>
          <ul>
             <li> Step 1: The base path MUST contain a version number.</li>
-            <li> Step 2: Each url of the server object of the OpenAPI Specification MUST include a version number.</li>
+            <li> Step 2: Each url of the server object of the OpenAPI Description MUST include a version number.</li>
             <li> Step 3: The version in the OAS file MUST be the same as the version in the base path.</li>
          </ul>
       </dd>
@@ -617,16 +594,12 @@ Changes in APIs are inevitable. APIs should therefore always be versioned, facil
       </dd>
       <dt>Implications</dt>
       <dd>
-         This rule is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The source code of the technical test can be found <a href="https://gitlab.com/commonground/don/adr-validator/-/blob/v0.5.0/pkg/rulesets/core/rules.go#L322">here</a>. The specific tests are published in the [[ADR-Validator]] repository.
+         This rule can be tested automatically and an example of the test is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The specific tests are published in the [[ADR-Validator]] repository.
       </dd>
       <dt>How to test</dt>
       <dd>
-         <ul>
-            <li> Step 1: The API MUST meet the prerequisets to be tested. These include that an OAS file (openapi.json) is publicly available, parsable, all $refs are resolvable and paths are defined.</li>
-            <li> Step 2: In the open api specification the info and version object MUST be available.</li>
-            <li> Step 3: The version MUST comply with Semantic Versioning.</li>
-         </ul>
-      </dd> 
+         The "API-Version" response header MUST comply with Semantic Versioning.
+      </dd>
    </dl>
 </div>
 
@@ -649,14 +622,11 @@ Changes in APIs are inevitable. APIs should therefore always be versioned, facil
       </dd>
       <dt>Implications</dt>
       <dd>
-         This rule is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The source code of the technical test can be found <a href="https://gitlab.com/commonground/don/adr-validator/-/blob/v0.5.0/pkg/rulesets/core/rules.go#L354">here</a>. The specific tests are published in the [[ADR-Validator]] repository.
+         This rule can be tested automatically and an example of the test is included in the automatic tests on <a href="https://developer.overheid.nl/">developer.overheid.nl</a>. The specific tests are published in the [[ADR-Validator]] repository.
       </dd>
       <dt>How to test</dt>
       <dd>
-         <ul>
-            <li> Step 1: A request to the base url MUST give a response and include the header "API-Version".</li>
-            <li> Step 2: The value of the header "API-Version" MUST have a valid Semantic Versioning number.</li>
-         </ul>
+         A response MUST include the header "API-Version".
       </dd>
    </dl>
 </div>

diff --git a/README.md b/README.md
@@ -6,7 +6,7 @@ De definitieve versie 2.0.0 is beschikbaar op: https://gitdocumentatie.logius.nl
 
 | Formele standaard                                            | Gepubliceerde versie                                         | Werk versie                                                  | Repository                                                   |
 | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
-| 🏛️[NLGov API Design Rules (ADR)](https://forumstandaardisatie.nl/open-standaarden/rest-api-design-rules) | 🍿 [ADR v1 (definitief)](https://gitdocumentatie.logius.nl/publicatie/api/adr/) | ✍️ [ADR v2.0.0-rc.2 (versie ter vaststelling)](https://logius-standaarden.github.io/API-Design-Rules/) | 🤓 [API-Design-Rules](https://github.com/Logius-standaarden/API-Design-Rules) |
+| 🏛️[NLGov API Design Rules (ADR)](https://forumstandaardisatie.nl/open-standaarden/rest-api-design-rules) | 🍿 [ADR 2.0.0 (definitief)](https://gitdocumentatie.logius.nl/publicatie/api/adr/) | ✍️ [ADR v2.0.0-rc.2 (versie ter vaststelling)](https://logius-standaarden.github.io/API-Design-Rules/) | 🤓 [API-Design-Rules](https://github.com/Logius-standaarden/API-Design-Rules) |
 | 🏛️[NLGov OAuth 2.0 profile (OAuth)](https://forumstandaardisatie.nl/open-standaarden/nl-gov-assurance-profile-oauth-20) | 🍿[OAuth v1 (definitief)](https://gitdocumentatie.logius.nl/publicatie/api/oauth/) | ✍️[OAuth v1.1.0 (werkversie)](https://logius-standaarden.github.io/OAuth-NL-profiel/) | 🤓[OAuth-NL-profiel](https://github.com/Logius-standaarden/OAuth-NL-profiel) |
 | 🏛️[NLGov OpenID Connect profile (OIDC)](https://forumstandaardisatie.nl/open-standaarden/nl-gov-assurance-profile-oidc) | 🍿[OIDC v1.0.1 (definitief)](https://gitdocumentatie.logius.nl/publicatie/api/oidc/) | ✍️[OIDC v1.0.1 (werkversie)](https://logius-standaarden.github.io/OIDC-NLGOV/) | 🤓[OIDC-NLGOV](https://github.com/Logius-standaarden/OIDC-NLGOV) |
 

diff --git a/js/config.js b/js/config.js
@@ -39,12 +39,12 @@ var respecConfig = {
     ],
   github: "https://github.com/Logius-standaarden/API-Design-Rules",
   pubDomain: "api",
-  publishDate: "2024-03-07",
-  publishVersion: "2.0.0",
-  previousPublishDate: "2020-07-09",
-  previousPublishVersion: "1.0",
+  publishDate: "2025-01-07",
+  publishVersion: "2.0.1",
+  previousPublishDate: "2024-03-07",
+  previousPublishVersion: "2.0.0",
   shortName: "adr",
-  specStatus: "def",
+  specStatus: "WV",
   specType: "ST",
   pluralize: true,
 };