인프런 커뮤니티 질문&답변
작성한 질문수
API 라우트 설계 시 중첩 구조 분리 기준 질문
작성
·
17
·
수정됨
0
안녕하세요 교수님
items나 users처럼 딱 떨어지는 리소스는 분리가 쉽지만, 실제로는 모델끼리 얽혀 있는 경우가 많아 라우팅이 모호해지곤 합니다.
예를 들어, /products라는 경로가 있음에도 불구하고 특정 맥락에 따라 /users/{user_id}/products와 같이 nested 방식 으로 접근해야 하는 상황이 자주 발생하는데요. (반대인 경우도 발생)
이렇게 데이터가 연결되어 있을 때 어디까지 경로를 중첩시킬지, 혹은 어느 시점에 라우트를 완전히 분리해야 할지 교수님만의 노하우나 팁이 있으실까요? 실무적인 관점에서 라우트 설계의 명확한 기준을 잡고 싶어 질문 드립니다.
추가로 데이터 모델과 라우트 이름을 보통 같게 하나요?
나중에 리팩토링 할 때 문제가 없을까요?
감사합니다!
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. 김근모님께서 API 라우트 설계 시 중첩 구조의 분리에 대해 질문해 주셨군요. 라우트 설계는 RESTful API 설계에서 매우 중요한 부분으로, 구조적이고 일관된 이름을 만드는 것이 매우 중요합니다. 여기에 몇 가지 일반적인 팁을 드리겠습니다.
리소스 중심의 설계: 라우트는 가능한 리소스 중심으로 설계하시는 것이 중요합니다.
/users/{user_id}/products와 같은 중첩 구조는 컨텍스트가 명확한 경우 유용하지만, 이 중첩이 데이터 흐름과 서비스를 복잡하게 만들 수 있습니다. 따라서, 가급적이면 리소스와 액션(HTTP 메서드)을 명확히 나누는 것이 좋습니다.경로의 깊이: 중첩된 경로는 이해하기 어려워지고 코드의 복잡성을 증가시킬 수 있습니다. 중첩이 깊어지면 해당 API의 목적을 잃을 위험이 있으므로 의도치 않은 복잡성을 피하세요.
믿을 수 있는 방향성: 특정 상황에서는 중첩보다는 매개 변수를 활용하여 필터링하거나 쿼리스트링을 사용하여 관계를 표현하는 방법이 더 명확할 수 있습니다.
모델과 라우트 이름 일치: 데이터 모델과 라우트 이름은 동일하게 가져가는 것이 보통의 관례지만, 직접적인 종속 관계가 되어 나중에 리팩토링 시 유연성을 잃지 않도록 주의해야 합니다.
관련된 답변 중 특히 이런 API 구성에 대한 토론을 다루는 질문도 많습니다. 유사한 질문과 답변들은 FastAPI와 관련된 많은 온라인 커뮤니티에서도 찾아보실 수 있습니다.
아래 링크를 통해 비슷한 주제를 다루고 있는 질문과 답변을 보실 수 있습니다:
- FastAPI와 함께 웹 개발을 전체적으로 다루시는 강의를 출시한 것을 확인
- AI 모델 서빙용으로 FastAPI 강의
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.