The Response object's `default` field is confusing and inconsistently interpreted

According both 3.0 and 3.1, in theResponse object there MUST be at least one response code and it SHOULD be the response for a successful operation call. In addition the default describes “responses other than the ones declared for specific HTTP response codes”.

This means that if we had a 200 response and default, the latter would cover everything except for 200. Many seem to interpret default to mean something like response categories not covered by explicit response codes. Consider this example from the OAI org:

responses:
        '200':
          description: pet response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Pet'
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'

https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml

This implies that default covers error types when in fact it covers non-error responses as well. In fact, the consumer wouldn't necessarily know if the API might reply with another success code such as a 204. A more precise example might look like this:

responses:
        '200':
          description: pet response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Pet'
        4xx:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
        5xx:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'

I would suggest the following actions:

1. Update the example to interpret the spec more literally
2. Clarify default since this confusion is not limited to this example, but extends to APIs in the wild
3. Consider in 3.2 or 4.0 eliminating default
4. Consider in 3.2 or 4.0 adding a new named error category that means "both 4xx and 5xx". This could be used in the way that default is often misused today

Inizia esaminando examples/v3.0/petstore-expanded.yaml e le definizioni dell’oggetto Response per OpenAPI 3.0 e 3.1. Confronta il significato documentato di default con la gestione degli errori prevista dall’esempio, quindi individua quale chiarimento o aggiornamento dell’esempio sia attuabile; per completare il lavoro sarebbe necessario concordare una modifica alla specifica o agli esempi.