no-http-verbs-in-paths

Disallows HTTP verbs used in paths.

List of HTTP verbs:

• get
• head
• post
• put
• patch
• delete
• options
• trace

API design principles

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. There is the option to splitIntoWords to reduce false positives. Imagine a world-famous rock band, the Redockers, and they have an API powering their music tour with one resource "posters". With the splitIntoWords enabled it will be identified as a resource and not trigger a false positive even though it contains the word post.

Configuration

An example configuration:

rules:
  no-http-verbs-in-paths: error

An example configuration with splitIntoWords enabled:

rules:
  no-http-verbs-in-paths:
    severity: error
    splitIntoWords: true

Examples

Given this configuration:

rules:
  no-http-verbs-in-paths: error

Example of an incorrect path:

paths:
  /getcustomers:
    $ref: ./paths/customer.yaml

Example of a correct path:

paths:
  /customers:
    $ref: ./paths/customer.yaml

Given the following configuration:

rules:
  no-http-verbs-in-paths:
    severity: error
    splitIntoWords: true

Example of an incorrect path:

paths:
  /getCustomers:
    $ref: ./paths/customer.yaml

Example of a correct path:

paths:
  /getcustomers:
    $ref: ./paths/customer.yaml

This last example wouldn't trigger an error because the casing won't split "get" into its own word.

Related rules

• custom rules
• path-excludes-patterns

Resources

• Rule source
• Paths docs