API Versioning 방식 변경 (#93)

[sungjindev]

⭐️ Issue Number

• API Versioning 방식 변경 #93

🚩 Summary

현재 API Versioning을 위해서 URI Versioning 방식을 사용하고 있습니다.
최근 클라이언트 단의 요청에 따라 Version과 관련된 Path가 더 뒤에 배치되는 것이 관리하기가 좋다는 피드백이 들어와 앞으로 배포되는 API는 모두 해당 방식으로 구현할 예정이며 기존에 이미 존재하는 API들은 운영에 이슈가 생기지 않도록 당분간은 API Versioning 두 가지 방식을 모두 채택하여 구현해놓으려고 합니다. 참고로 아래는 현 방식과 앞으로 바꾸게되는 방식 예시입니다.

[현 방식]
/api/v1/findStores/byLocation

[바꿀 방식]
/api/findStores/byLocation/v1

• 기존에 존재하던 API들을 유지함과 동시에 새로운 Versioning 방식의 API들도 만들기

🛠️ Technical Concerns

API Versioning 방식에 대한 고민

먼저 클라이언트 개발 측으로부터 API Versioning path의 위치를 조정해줬으면 좋겠다라는 의견이 있었고 그 후 어떤 방식의 Versioning을 취하는 것이 가장 이점이 많을지 고민하였습니다.

API Versioning 관련해서 크게 4가지 방법이 있었습니다.

1. URI 방식
2. Query Request Parameter 방식
3. Custom Header 방식
4. MIME type 방식

그 중에서도 저희는 이미 V3.0.0 애플리케이션을 운영중이고 이전 버전에 대한 사용자들이 존재한다는 점, 아직 클라이언트 단에서 Deprecated될 버전을 사용하고 있는 사용자들에게 업데이트를 강제하는 로직을 구현하지 못했다는 점 등을 고려해서 최대한 변경 요소를 줄이기 위해 기존에 사용하던 URI 방식을 클라이언트 측의 요구 및 필요에 맞게 변경하기로 결정하였습니다.

📋 To Do

• 검색어 자동 완성 기능에 대한 공부와 구현

[github-actions]

Test Results

11 tests  ±0   11 ✅ ±0   15s ⏱️ -4s
 8 suites ±0    0 💤 ±0 
 8 files   ±0    0 ❌ ±0 

Results for commit e9bcdf7. ± Comparison against base commit 1aa1cc9.

[jinhoon227]

승인합니다!