refactor(uri): api uri 구조 변경 (#231)

[mintjordy]

resolves #231

전반적으로 uri 리팩토링 마쳤습니다.

기존에 태그의 카테고리 변경을 category controller에서 작업 하던 것을 tag controller 로 옮기는 과정에서 순환참조 이슈가 있었습니다.

category controller

• uncategorized 를 포함한 모든 카테고리 및 그 이하 태그 목록 조회 (Category Service에서 TagService 의존)
• 카테고리 이름 수정
• 카테고리 등록
• 카테고리 삭제
• 특정 태그의 소속 카테고리 변경(Category Service 사용) (tag로 이동 했기 때문에 TagService에서 Cartegory Service 의존)

위에 볼드체로 표시한 기능들이 서로 Service를 참조하기 때문에 발생한 순환 참조였는데, 우선은 Service 대신 Repository를 참조하도록 하여 일시적으로 순환참조가 일어나지 않도록 했습니다.

해당 순환 참조 이슈에 대해 어떻게 하면 좋을지 여러분들 의견이 듣고 싶네요!

---

uri 변경 내역은 커밋 메시지로 남겨놓았으니 참조하시면 좋을 것 같습니다!

[KS-KIM]

category service와 tag service간의 양방향 의존은 findAllTagsBy 메서드로부터 발생한 것 같아요. 과연 저 메서드가 category 서비스에 있는게 맞을까요?

[mintjordy]

category service와 tag service간의 양방향 의존은 findAllTagsBy 메서드로부터 발생한 것 같아요. 과연 저 메서드가 category 서비스에 있는게 맞을까요?

음... 이부분에 대해서는 고민이 필요한 것 같아요. 사실 categoryService의 findAllTagsBy 메서드는 Category, Tag 두 서비스의 메서드를 의존하면서 순환참조를 발생하게 했죠. 사실 둘 중에 한 서비스에 위치시키는 방법으로는 결국 의존도를 약화 시키기는 어려워 보이네요.

차라리 categoryService와 tagService 의 조합이 필요한 경우 아예 새로운 서비스를 만드는 방법도 있을 것 같은데 알트는 어떻게 생각하시나요?