---

Al construir APIs, normalmente usas estos métodos HTTP específicos para realizar una acción específica.

Normalmente usas:

* `POST`: para crear datos.
* `GET`: para leer datos.
* `PUT`: para actualizar datos.
* `DELETE`: para eliminar datos.

Así que, en OpenAPI, cada uno de los métodos HTTP se llama una "operation".

Vamos a llamarlas "**operaciones**" también.

    * Autocompletado.
    * Chequeo de tipos.
* Validación de datos:
    * Errores automáticos y claros cuando los datos son inválidos.
    * Validación incluso para objetos JSON profundamente anidados.
* <dfn title="también conocido como: serialización, parsing, marshalling">Conversión</dfn> de datos de entrada: de la red a los datos y tipos de Python. Leyendo desde:
    * JSON.
    * Parámetros de path.

Por ejemplo, podrías querer **devolver un diccionario** u objeto de base de datos, pero **declararlo como un modelo de Pydantic**. De esta manera el modelo de Pydantic haría toda la documentación de datos, validación, etc. para el objeto que devolviste (por ejemplo, un diccionario u objeto de base de datos).

### Revisa el password { #check-the-password }

En este punto tenemos los datos del usuario de nuestra base de datos, pero no hemos revisado el password.

Primero pongamos esos datos en el modelo `UserInDB` de Pydantic.

Nunca deberías guardar passwords en texto plano, así que, usaremos el sistema de hash de passwords (falso).

Si los passwords no coinciden, devolvemos el mismo error.

llamado marshalling, conversión">serialización</dfn>" de datos, que consiste en tomar datos del código (Python) y convertirlos en algo que pueda ser enviado a través de la red. Por ejemplo, convertir un objeto que contiene datos de una base de datos en un objeto JSON. Convertir objetos `datetime` en strings, etc.

Otra gran funcionalidad necesaria por las APIs es la validación de datos, asegurarse de que los datos sean válidos, dados ciertos parámetros. Por ejemplo, que algún campo sea un...

Muchos paquetes que lo simplifican tienen que hacer muchos compromisos con el modelo de datos, la base de datos y las funcionalidades disponibles. Y algunos de estos paquetes que simplifican las cosas demasiado en realidad tienen fallos de seguridad en el fondo.

---

**FastAPI** no hace ningún compromiso con ninguna base de datos, modelo de datos o herramienta.

errors.crud_failed_to_create_instance = No se pudieron crear nuevos datos.
errors.crud_failed_to_create_crud_table = No se pudieron crear nuevos datos. ({0})
errors.crud_failed_to_update_crud_table=No se pudieron actualizar los datos. ({0})
errors.crud_failed_to_delete_crud_table=No se pudieron eliminar los datos. ({0})
errors.crud_could_not_find_crud_table = No se encontraron los datos {0}.

# Bases de Datos SQL (Relacionales) { #sql-relational-databases }

**FastAPI** no requiere que uses una base de datos SQL (relacional). Pero puedes utilizar **cualquier base de datos** que desees.

Aquí veremos un ejemplo usando [SQLModel](https://sqlmodel.tiangolo.com/).

* Todas las dependencias pueden requerir datos de los requests y **aumentar las restricciones de la path operation** y la documentación automática.
* **Validación automática** incluso para los parámetros de *path operation* definidos en las dependencias.
* Soporte para sistemas de autenticación de usuario complejos, **conexiones a bases de datos**, etc.
* **Sin compromisos** con bases de datos, frontends, etc. Pero fácil integración con todos ellos.

Verás ejemplos de esto en los próximos capítulos, sobre bases de datos relacionales y NoSQL, seguridad, etc.

## Compatibilidad de **FastAPI** { #fastapi-compatibility }

La simplicidad del sistema de inyección de dependencias hace que **FastAPI** sea compatible con:

* todas las bases de datos relacionales
* bases de datos NoSQL
* paquetes externos
* APIs externas
* sistemas de autenticación y autorización