## 기능 요청 **기능에 대한 간단한 설명:** - 현재 FastAPI 서버의 일부 API 경로 및 응답 구조가 RESTful한 설계 원칙에 부합하지 않음 - 기능 기반의 경로(`/create`, `/save_log` 등)를 리소스 중심의 RESTful URL로 개편 필요 - HTTP 메서드(GET, POST, PUT, PATCH, DELETE)의 의미에 맞게 API 동작 재정의 **필요한 이유:** - RESTful한 API 설계를 통해 경로만 보고도 기능을 직관적으로 유추할 수 있음 - 내부 연동 시스템에서 API 사용성을 개선(SpringBoot) - 유지보수성과 문서화(OpenAPI 기반)에서 명확한 기준 수립 가능 **기능의 예상 동작:** - 기존 `/create`, `/save_log`, `/load_log` 등의 경로를 `/chatrooms/`, `/chatrooms/{room_id}/logs/`와 같은 RESTful 구조로 변경 - HTTP 상태 코드 및 응답 메시지를 REST 표준에 맞게 재정의 (예: 201 Created, 204 No Content 등) - API 문서에서도 엔드포인트 구조가 논리적으로 분리되며 가독성 향상 - 관련된 요청 및 응답 모델 이름도 `ChatRoomCreateRequest`, `ChatLogUpdateRequest` 등으로 명확히 분리 **추가 정보:** - 참고 링크: [RESTful API 디자인 가이드](https://restfulapi.net/resource-naming/) - 향후 Swagger 문서 및 외부 파트너 API 공유 시 구조적 이점 발생 예상 **우선순위:** - 중간 (서비스 기능에는 영향 없으나 구조적 개선으로 중요도는 있음) **기타 의견:** - 리팩토링 작업 시 기존 API를 deprecated 처리하거나 병행 운영 고려 필요 - 라우터 분기도 함께 수정되어야 함
기능 요청
기능에 대한 간단한 설명:
/create,/save_log등)를 리소스 중심의 RESTful URL로 개편 필요필요한 이유:
기능의 예상 동작:
/create,/save_log,/load_log등의 경로를/chatrooms/,/chatrooms/{room_id}/logs/와 같은 RESTful 구조로 변경ChatRoomCreateRequest,ChatLogUpdateRequest등으로 명확히 분리추가 정보:
우선순위:
기타 의견: