E com qualquer retorno que você desejar.

Neste caso, a dependência espera por:

* Um parâmetro de consulta opcional `q` do tipo `str`.
* Um parâmetro de consulta opcional `skip` do tipo `int`, e igual a `0` por padrão.
* Um parâmetro de consulta opcional `limit` do tipo `int`, e igual a `100` por padrão.

E então retorna um `dict` contendo esses valores.

/// info | Informação

Debido a que cada modelo de SQLModel también es un modelo de Pydantic, puedes usarlo en las mismas **anotaciones de tipos** que podrías usar en modelos de Pydantic.

Por ejemplo, si declaras un parámetro de tipo `Hero`, será leído desde el **JSON body**.

De la misma manera, puedes declararlo como el **tipo de retorno** de la función, y luego la forma de los datos aparecerá en la interfaz automática de documentación de la API.

Primeiro, importe `BackgroundTasks` e defina um parâmetro na sua *função de operação de rota* com uma declaração de tipo `BackgroundTasks`:

{* ../../docs_src/background_tasks/tutorial001_py39.py hl[1,13] *}

O **FastAPI** criará o objeto do tipo `BackgroundTasks` para você e o passará como esse parâmetro.

## Crie uma função de tarefa { #create-a-task-function }

* «/// info»: «/// info | Informação»
* «/// note | Technical Details»: «/// note | Detalhes Técnicos»
* «/// info | Very Technical Details»: «/// note | Detalhes Técnicos Avançados»
* «/// note»: «/// note | Nota»
* «/// tip»: «/// tip | Dica»
* «/// warning»: «/// warning | Atenção»
* «(you should)»: «(você deveria)»
* async context manager: gerenciador de contexto assíncrono
* autocomplete: autocompletar
* autocompletion: preenchimento automático

* `skip`: com o valor `0`
* `limit`: com o valor `10`

Como eles são parte da URL, eles são "naturalmente" strings.

Mas quando você declara eles com os tipos do Python (no exemplo acima, como `int`), eles são convertidos para aquele tipo e validados em relação a ele.

Todo o processo que era aplicado para parâmetros de rota também é aplicado para parâmetros de consulta:

* Suporte do editor (obviamente)

...los parámetros de query son:

* `skip`: con un valor de `0`
* `limit`: con un valor de `10`

Como son parte de la URL, son "naturalmente" strings.

Pero cuando los declaras con tipos de Python (en el ejemplo anterior, como `int`), son convertidos a ese tipo y validados respecto a él.

Todo el mismo proceso que se aplica para los parámetros de path también se aplica para los parámetros de query:

* Soporte del editor (obviamente)

## Metadata para la API { #metadata-for-api }

Puedes establecer los siguientes campos que se usan en la especificación OpenAPI y en las interfaces automáticas de documentación de la API:

| Parámetro | Tipo | Descripción |
|------------|------|-------------|
| `title` | `str` | El título de la API. |
| `summary` | `str` | Un resumen corto de la API. <small>Disponible desde OpenAPI 3.1.0, FastAPI 0.99.0.</small> |

## Metadados para API { #metadata-for-api }

Você pode definir os seguintes campos que são usados na especificação OpenAPI e nas interfaces automáticas de documentação da API:

| Parâmetro | Tipo | Descrição |
|------------|------|-------------|
| `title` | `str` | O título da API. |
| `summary` | `str` | Um breve resumo da API. <small>Disponível desde OpenAPI 3.1.0, FastAPI 0.99.0.</small> |

# Webhooks de OpenAPI { #openapi-webhooks }

Hay casos donde quieres decirle a los **usuarios** de tu API que tu aplicación podría llamar a *su* aplicación (enviando una request) con algunos datos, normalmente para **notificar** de algún tipo de **evento**.

Esto significa que en lugar del proceso normal de tus usuarios enviando requests a tu API, es **tu API** (o tu aplicación) la que podría **enviar requests a su sistema** (a su API, su aplicación).

///

/// tip | Consejo

Para declarar cuerpos de File, necesitas usar `File`, porque de otra manera los parámetros serían interpretados como parámetros query o parámetros de cuerpo (JSON).

///

Los archivos se subirán como "form data".