반응형
프로젝트가 커지면 라우팅이 제일 먼저 난장판 된다.
main.py에 라우터가 다 붙어있음- 엔드포인트가 늘어나면 파일 하나가 1,000줄 넘어감
/v1,/v2같은 버전이 필요해졌을 때… “아 망했다” 느낌
그래서 나는 처음부터 라우터를 두 레벨로 나눴다.
- root_router: 버전이 없는 엔드포인트(헬스체크 같은 거)
- api_router:
/api/v1아래로 들어가는 실제 API
핵심 코드: root_router vs api_router
구조는 단순하다.
root_router = APIRouter()
root_router.include_router(health_router)
api_router = APIRouter()
api_router.include_router(diaries_router)
api_router.include_router(weather_router)그리고 app 생성할 때 이렇게 붙인다.
app.include_router(root_router)
app.include_router(api_router, prefix=settings.api_v1_prefix)여기서 포인트는 2개.
1) 헬스체크는 버저닝을 안 타는 게 운영에서 편하다
예를 들어 로드밸런서나 모니터링에서 /health만 때려보고 싶을 때가 많다.
그때 /api/v1/health처럼 “API 버전”을 의존하게 만들면, 버전 정책 바뀔 때 운영도 같이 흔들린다.
그래서 그냥 /health로 둔다.
curl -sS http://127.0.0.1:8000/health2) 실제 비즈니스 API는 /api/v1로 “경계”를 만들어준다
이 경계는 나중에 진짜 도움이 된다.
/api/v1/diaries/api/v1/weather
버전이 필요해지면 Settings.api_v1_prefix만 바꾸거나, /api/v2를 새로 만들고 라우터 세트를 갈아끼우면 된다.
실습: 라우팅이 제대로 붙었는지 한 번에 확인
서버를 띄운 뒤, 아래 3개를 쏴보자.
curl -sS http://127.0.0.1:8000/health
curl -sS "http://127.0.0.1:8000/api/v1/diaries"
curl -sS "http://127.0.0.1:8000/api/v1/weather?lat=37.57&lng=126.98"/health는 무조건 200이 떠야 정상/api/v1/diaries는 DB 비어있으면[]가 나오는 게 정상/api/v1/weather는 키가 없으면 503, 있으면 200 (둘 다 “의도된 동작”)
마무리
라우팅은 초반에 구조 잡아두면 이후에 “정신 건강”이 달라진다 ㅋㅋ
다음 편에서는 DB로 넘어가서 SQLModel로 MVP DB를 어떻게 구성했는지 본다.
참고
반응형
