No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Esqueleto de las Path Operations: Tweets

19/25
Recursos

Aportes 10

Preguntas 4

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Regístrate o inicia sesión para participar.

Para los endpoints donde pasamos el id
por ejemplo:

/tweets/{tweet_id}

la diagonal siguiente del path no es necesario ponerla, ya que la acción la estamos diciendo en el verbo de la petición .
De este modo

@app.delete(
    path="/tweets/{tweet_id}",

@app.get(
    path="/tweets/{tweet_id}",

obtendremos la correspondiente acción a la petición sin necesidad de /delete o /update. Lo mismo para Users.

A medida que voy avanzando en las clases y cursos con @FacuandoGarciaMartoni

Me tarde buen rato buscando donde estaba el error, ya que cuando entraba a /docs no cargaba

Y era una coma que se fue de mas en el modelo de User 😅

Para evitar que alguien pierda el tiempo como yo lo hize aca les dejo una recomendación:

Siempre revisen los “()” al final de los metodos 😅

por no hacerlo acá (despues del metod now)

obtenía y seguía obteniendo este error

y no podia ver la documentación interactiva

Buenas a todos, os dejo un aporte de cómo modularizar el código del proyecto en diferentes archivos y paquetes para que
no tengamos el código en un solo archivo.

Si tomáis cualquier clase de los otros lenguajes de programación en Platzi lo explican desde el principio para tener un
código más limpio. No entiendo por qué el Python no lo hace el profesor de esta manera, pienso que será por intentar
facilitar el aprendizaje.

Os dejo un aporte de cómo la documentación de la FastApi aconseja hacerlo espero os sirva de ayuda. Por si alguien más
quiere implementarlo.

La estructura de carpetas que he utilizado es la siguiente aunque no es obligatoria esta nomenclatura:

- controllers
	- __init__.py
	- auth.py
	- tweet.py
	- user.py
-models
	- __init__.py
	- Tweet.py
	- User.py
-venv
.gitignore
main.py
README.md
requirements.py

En models meteremos todos los modelos que necesite nuestra aplicación

En controllers meteremos todos los endpoints

Ejemplo de como se vería models / Tweet.py

from uuid import UUID
from datetime import datetime
from typing import Optional

from pydantic import BaseModel, Field

from models import User


class Tweet(BaseModel):
    tweet_id: UUID = Field(...)
    content: str = Field(
        ...,
        min_length=1,
        max_length=256
    )
    created_at: datetime = Field(default=datetime.now())
    updated_at: Optional[datetime] = Field(default=None)
    by: User = Field(...)

El archivo models / __init__.py sirve para concentrar todo lo que queremos mostrar a otros paquetes. Y seria tan
simple
como:

from .User import User, UserLogin
from .Tweet import Tweet

Ahora veremos los controllers estos cambia un poco de como los usa el profesor porque ahora tendremos routers entre
medias, para quien venga de JavaScript es igual que Express

Ejemplo del archivo controllers / tweet.py:

from typing import List

from fastapi import APIRouter, status

from models import Tweet

router = APIRouter(
    prefix="/tweets",
    tags=["Tweets"],
)


@router.get(
    path="/",
    response_model=List[Tweet],
    status_code=status.HTTP_200_OK,
    summary="Show all tweets",
)
def get_all():
    pass


@router.get(
    path="/{tweet_id}",
    response_model=Tweet,
    status_code=status.HTTP_200_OK,
    summary="Show a Tweet",
)
def get_one():
    pass


@router.post(
    path="/",
    response_model=Tweet,
    status_code=status.HTTP_201_CREATED,
    summary="Post a Tweet",
)
def post():
    pass


@router.delete(
    path="/{tweet_id}",
    response_model=Tweet,
    status_code=status.HTTP_200_OK,
    summary="Delete a Tweet",
)
def delete():
    pass


@router.put(
    path="/{tweet_id}",
    response_model=Tweet,
    status_code=status.HTTP_200_OK,
    summary="Update a Tweet",
)
def update():
    pass

Como veis en lugar de inicializar FastApi() inicializamos ApiRouter() pero funciona de igual manera, Como parámetros a
ApiRouter() veréis que le paso prefix y tags, todo lo que apliques a un Router se aplica a todas sus rutas hijas por
ellos si ponemos tags en el router todas las demás rutas tendrán ese tag y prefix es para no tener que poner en cada
path= tweets/resto_de_la_ruta, porque si lo pones en el router ya esta automáticamente en todas.

Esos parámetros no son obligatorios y podéis hacerlo como el profesor y ponerlo en cada ruta.

Ahora en el archivo controllers / __init__.py creamos el router principal de la app y se queda algo como esto:

from fastapi import APIRouter

from .user import router as user_router
from .tweet import router as tweet_router
from .auth import router as auth_router

router = APIRouter(
    prefix="/api"
)

router.include_router(user_router)
router.include_router(tweet_router)
router.include_router(auth_router)

Simplemente, es la union de todos los pequeños routers como veis le añado prefix="/api" esto es algo que os encontraréis
en la mayoría de Api que la ruta para acceder a ellas siempre empieza con nuestro_dominio / api / resto_de_la_ruta como
es dicho ante esto no es necesario, y si no queremos que tenga api en la ruta simplemente no ponemos el prefix

Y por último este es el archivo main.py de la app aquí solo inicializamos el server con FastApi() y le pasamos el router
para que lo use

from fastapi import FastAPI

from controllers import router

app = FastAPI()

app.include_router(router)

Como veis el import del router es de nuestro paquete controllers, no tenéis que instalar ningún paquete externo ni nada
para hacer esto.

En principio mucha gente verá esto y se asustará un poco, pero pensar que cuando empecéis a trabajar nunca os dejaran
crear todo en un solo archivo y cuando te acostumbras un poco a este tipo de orden es mucho más cómodo.

Me parece redundante poner un comentario el cual dice literalmente lo mismo tanto en la función, como en el summary.
¿Se considera eso una buena práctica?
¿O es con el fin de añadir más información valiosa en el futuro?

## Tweets

### Show all tweets
@app.get(
    path='/',
    response_model=List[Tweet],
    status_code=status.HTTP_200_OK,
    summary='Show all tweets',
    tags=['Tweets']
)
def home():
    return {'Twitter API': 'Working!'}

### Post a tweet
@app.post(
    path='/post',
    response_model=Tweet,
    status_code=status.HTTP_201_CREATED,
    summary='Post a tweet',
    tags=['Tweets']
)
def post():
    pass

### Show a tweet
@app.get(
    path='/tweet/{tweet_id}',
    response_model=Tweet,
    status_code=status.HTTP_200_OK,
    summary='Show a tweet',
    tags=['Tweets']
)
def show_a_tweet():
    pass

### Delete a tweet
@app.delete(
    path='/tweet/{tweet_id}',
    response_model=Tweet,
    status_code=status.HTTP_200_OK,
    summary='Delete a tweet',
    tags=['Tweets']
)
def delete_a_tweet():
    pass

### Update a tweet
@app.put(
    path='/tweet/{tweet_id}',
    response_model=Tweet,
    status_code=status.HTTP_200_OK,
    summary='Update a tweet',
    tags=['Tweets']
)
def update_a_tweet():
    pass

Facu dice en posteriores entregas, pero no hay ninguna entrega de FastAPI en el calendario T_T, pero bueno nos dejo con buenas bases para meterle duro a la documentación.