<img src="/img/tutorial/generate-clients/image01.png">

Puedes ver esos esquemas porque fueron declarados con los modelos en la aplicación.

Esa información está disponible en el **JSON Schema** de OpenAPI de la aplicación, y luego se muestra en la documentación de la API (por Swagger UI).

Y esa misma información de los modelos que está incluida en OpenAPI es lo que puede usarse para **generar el código del cliente**.

Puedes usar `jsonable_encoder` para eso.

Recibe un objeto, como un modelo de Pydantic, y devuelve una versión compatible con JSON:

{* ../../docs_src/encoder/tutorial001_py310.py hl[4,21] *}

En este ejemplo, convertiría el modelo de Pydantic a un `dict`, y el `datetime` a un `str`.

Fess también incluye un rastreador (crawler), que puede rastrear documentos en un [servidor web](https://fess.codelibs.org/14.17/admin/webconfig-guide.html), [sistema de archivos](https://fess.codelibs.org/14.17/admin/fileconfig-guide.html), o [almacenamiento de datos](https://fess.codelibs.org/14.17/a...

Y la especificación dice que los campos deben llamarse así. Por lo que `user-name` o `email` no funcionarían.

Pero no te preocupes, puedes mostrarlo como quieras a tus usuarios finales en el frontend.

Y tus modelos de base de datos pueden usar cualquier otro nombre que desees.

Es posible recibir headers duplicados. Eso significa, el mismo header con múltiples valores.

Puedes definir esos casos usando una lista en la declaración del tipo.

Recibirás todos los valores del header duplicado como una `list` de Python.

Por ejemplo, para declarar un header de `X-Token` que puede aparecer más de una vez, puedes escribir:

{* ../../docs_src/header_params/tutorial003_an_py310.py hl[9] *}

# Cookies de Response

## Usar un parámetro `Response`

Puedes declarar un parámetro de tipo `Response` en tu *path operation function*.

Y luego puedes establecer cookies en ese objeto de response *temporal*.

{* ../../docs_src/response_cookies/tutorial002.py hl[1, 8:9] *}

Y entonces puedes devolver cualquier objeto que necesites, como normalmente lo harías (un `dict`, un modelo de base de datos, etc).

Por ejemplo, en una de las formas en las que se puede usar la especificación OAuth2 (llamada "password flow") se requiere enviar un `username` y `password` como campos de formulario.

La <abbr title="specification">especificación</abbr> requiere que los campos se llamen exactamente `username` y `password`, y que se envíen como campos de formulario, no JSON.

{* ../../docs_src/extending_openapi/tutorial001.py hl[2,15:21] *}

### Modificar el esquema de OpenAPI

Ahora puedes añadir la extensión de ReDoc, agregando un `x-logo` personalizado al "objeto" `info` en el esquema de OpenAPI:

{* ../../docs_src/extending_openapi/tutorial001.py hl[22:24] *}

### Cachear el esquema de OpenAPI

Puedes usar la propiedad `.openapi_schema` como un "cache", para almacenar tu esquema generado.

Eso significa que, los clientes que usan tu API no tienen que comprobar si el valor existe o no, pueden **asumir que el campo siempre estará allí**, pero solo que en algunos casos tendrá el valor por defecto de `None`.

La forma de describir esto en OpenAPI es marcar ese campo como **requerido**, porque siempre estará allí.

Debido a eso, el JSON Schema para un modelo puede ser diferente dependiendo de si se usa para **entrada o salida**:

# Código de Estado del Response

De la misma manera que puedes especificar un modelo de response, también puedes declarar el código de estado HTTP usado para el response con el parámetro `status_code` en cualquiera de las *path operations*:

* `@app.get()`
* `@app.post()`
* `@app.put()`
* `@app.delete()`
* etc.

{* ../../docs_src/response_status_code/tutorial001.py hl[6] *}

/// note | Nota