## Futuro { #future }

A este punto, ya está claro que **FastAPI** con sus ideas está siendo útil para muchas personas.

Está siendo elegido sobre alternativas anteriores por adaptarse mejor a muchos casos de uso.

## Futuro { #future }

Nesse ponto, já está claro que o **FastAPI** com suas ideias está sendo útil para muitas pessoas.

Ele foi escolhido sobre outras alternativas anteriores por se adequar melhor em muitos casos.

Pero no puedes convertir del galimatías de nuevo a la contraseña.

### Por qué usar hashing de contraseñas { #why-use-password-hashing }

Si tu base de datos es robada, el ladrón no tendrá las contraseñas en texto claro de tus usuarios, solo los hashes.

Por lo tanto, el ladrón no podrá intentar usar esa contraseña en otro sistema (como muchos usuarios usan la misma contraseña en todas partes, esto sería peligroso).

Então, mesmo com o código acima que não usa Pydantic explicitamente, o FastAPI está usando Pydantic para converter essas dataclasses padrão para a versão do Pydantic.

E claro, ele suporta o mesmo:

* validação de dados
* serialização de dados
* documentação de dados, etc.

///

Agora o FastAPI vai:

* **Validar** os dados garantindo que o comprimento máximo seja de 50 caracteres
* Mostrar um **erro claro** para o cliente quando os dados não forem válidos
* **Documentar** o parâmetro na *operação de rota* do esquema OpenAPI (então ele aparecerá na **UI de docs automática**)

    hashed_password = hashed_password,
)
```

/// warning | Atenção

As funções adicionais de suporte `fake_password_hasher` e `fake_save_user` servem apenas para demonstrar um fluxo possível dos dados, mas é claro que elas não fornecem segurança real.

///

## Reduzir duplicação { #reduce-duplication }

Reduzir a duplicação de código é uma das ideias principais no **FastAPI**.

Ou você pode ter qualquer outra forma de comunicar com o endpoint WebSocket.

---

Mas para este exemplo, usaremos um documento HTML muito simples com algum JavaScript, tudo dentro de uma string longa.

Esse, é claro, não é o ideal e você não o usaria para produção.

Na produção, você teria uma das opções acima.

Mas é a maneira mais simples de focar no lado do servidor de WebSockets e ter um exemplo funcional:

* Leer el body del request como JSON.
* Convertir los tipos correspondientes (si es necesario).
* Validar los datos.
    * Si los datos son inválidos, devolverá un error claro e indicado, señalando exactamente dónde y qué fue lo incorrecto.
* Proporcionar los datos recibidos en el parámetro `item`.

* Ler o corpo da requisição como um JSON.
* Converter os tipos correspondentes (se necessário).
* Validar os dados.
    * Se algum dado for inválido, irá retornar um erro bem claro, indicando exatamente onde e o que estava incorreto.
* Entregar a você a informação recebida no parâmetro `item`.

```
http://127.0.0.1:8000/items/foo-item?needy=sooooneedy
```

...isso deve funcionar:

```JSON
{
    "item_id": "foo-item",
    "needy": "sooooneedy"
}
```

E claro, você pode definir alguns parâmetros como obrigatórios, alguns possuindo um valor padrão, e outros sendo totalmente opcionais:

{* ../../docs_src/query_params/tutorial006_py310.py hl[8] *}