Disallows HTTP verbs used in paths.
| OAS | Compatibility |
|---|---|
| 2.0 | ✅ |
| 3.0 | ✅ |
| 3.1 | ✅ |
| 3.2 | ✅ |
List of HTTP verbs:
getheadpostputpatchdeleteoptionstrace
API designers generally fall into either a REST or RPC type. The REST type prefers to name paths after resources like "customers", and "payments". And the REST type relies on HTTP methods, like GET, to indicate the action on that resource. It would be considered a design fail to make the path "getcustomers" or "get-customers" or any variation on that. If you're aiming to design RESTful resources, then consider this rule your friend.
To reduce false positives, use the splitIntoWords option. Imagine a world-famous rock band, the Redockers, and they have an API powering their music tour with one resource "posters". With the splitIntoWords option enabled, "posters" is identified as a resource and does not trigger a false positive, even though it contains the word post.
| Option | Type | Description |
|---|---|---|
| severity | string | Possible values: off, warn, error. Default off (in recommended configuration). |
| splitIntoWords | boolean | Matches http verbs when the string is split into words based on casing. This can reduce false positives. Default false. |
An example configuration:
rules:
no-http-verbs-in-paths: errorAn example configuration with splitIntoWords enabled:
rules:
no-http-verbs-in-paths:
severity: error
splitIntoWords: trueGiven this configuration:
rules:
no-http-verbs-in-paths: errorExample of an incorrect path:
paths:
/getcustomers:
$ref: ./paths/customer.yamlExample of a correct path:
paths:
/customers:
$ref: ./paths/customer.yamlGiven the following configuration:
rules:
no-http-verbs-in-paths:
severity: error
splitIntoWords: trueExample of an incorrect path:
paths:
/getCustomers:
$ref: ./paths/customer.yamlExample of a correct path:
paths:
/getcustomers:
$ref: ./paths/customer.yamlThis last example wouldn't trigger an error because the casing doesn't split "get" into its own word.