```
http://127.0.0.1:8000/items/foo?short=true
```

o

```
http://127.0.0.1:8000/items/foo?short=on
```

o

```
http://127.0.0.1:8000/items/foo?short=yes
```

o cualquier otra variación (mayúsculas, primera letra en mayúscula, etc.), tu función verá el parámetro `short` con un valor `bool` de `True`. De lo contrario, será `False`.

## Múltiples parámetros de path y de query

O podrías tener una aplicación móvil nativa que se comunica con tu backend de WebSocket directamente, en código nativo.

O podrías tener alguna otra forma de comunicarte con el endpoint de WebSocket.

---

Pero para este ejemplo, usaremos un documento HTML muy simple con algo de JavaScript, todo dentro de un string largo.

## Documentar el callback

El código real del callback dependerá mucho de tu propia aplicación API.

Y probablemente variará mucho de una aplicación a otra.

Podría ser solo una o dos líneas de código, como:

```Python
callback_url = "https://example.com/api/v1/invoices/events/"
httpx.post(callback_url, json={"description": "Invoice paid", "paid": True})
```

* **Sin compromisos** con bases de datos, frontends, etc. Pero fácil integración con todos ellos.

### "Plug-ins" ilimitados

O de otra manera, no hay necesidad de ellos, importa y usa el código que necesitas.

# Manejo de Errores

Existen muchas situaciones en las que necesitas notificar un error a un cliente que está usando tu API.

Este cliente podría ser un navegador con un frontend, un código de otra persona, un dispositivo IoT, etc.

Podrías necesitar decirle al cliente que:

* El cliente no tiene suficientes privilegios para esa operación.
* El cliente no tiene acceso a ese recurso.
* El ítem al que el cliente intentaba acceder no existe.
* etc.

* Tampoco te preocupes por las reglas de estilo, hay herramientas automatizadas verificando eso.

Y si hay alguna otra necesidad de estilo o consistencia, pediré directamente eso, o agregaré commits encima con los cambios necesarios.

### Revisa el código

Primero vamos a ver cómo los editores, mypy y otras herramientas verían esto.

`BaseUser` tiene los campos base. Luego `UserIn` hereda de `BaseUser` y añade el campo `password`, por lo que incluirá todos los campos de ambos modelos.

Anotamos el tipo de retorno de la función como `BaseUser`, pero en realidad estamos devolviendo una instancia de `UserIn`.

<img src="/img/tutorial/custom-response/image01.png">

## Responses disponibles

Aquí hay algunos de los responses disponibles.

Ten en cuenta que puedes usar `Response` para devolver cualquier otra cosa, o incluso crear una sub-clase personalizada.

/// note | Nota Técnica

También podrías usar `from starlette.responses import HTMLResponse`.

Hay algunas diferencias:

* `table=True` le dice a SQLModel que este es un *modelo de tabla*, que debe representar una **tabla** en la base de datos SQL, no es solo un *modelo de datos* (como lo sería cualquier otra clase regular de Pydantic).

* `Field(primary_key=True)` le dice a SQLModel que `id` es la **clave primaria** en la base de datos SQL (puedes aprender más sobre claves primarias de SQL en la documentación de SQLModel).

///

## Lista de parámetros de Query / múltiples valores

Cuando defines un parámetro de query explícitamente con `Query` también puedes declararlo para recibir una lista de valores, o dicho de otra manera, para recibir múltiples valores.

Por ejemplo, para declarar un parámetro de query `q` que puede aparecer varias veces en la URL, puedes escribir: