HTTP has a well-understood set of meanings that sometimes conflicts with the spec. Here we set a more clear standard that is applicable to the product

The RFC states that HTTP statuses are extensible, and e.g. any unrecognized 4xx code MUST be treated as a 400 by any client that doesn’t understand it. We could use that to our advantage, though we should tread carefully here

Statuses

HTTP Statuses

Error Type descriptions

Error conditions

• The software itself has changed (On Versioning)
  • A capability that was formerly available is now disallowed, in a manner unforeseen by the schema designer. This would result in a 405c

Methods & Responses

Here are the default semantics, where applicable, of HTTP methods on resource classes. Either this happens, or one of the Implicit conditions above is rendered, and must be handled by the client.

These are assumed on every resource class, and can be overridden or left implied. The details of these responses can be left implicit too, so that documentation can be added without having to redundantly specify details