♻️ API 스펙 리펙터링 #13
♻️ API 스펙 리펙터링 #13
Conversation
waterfogSW
requested review from
dojinyou,
jisu15-kim and
moondev03
as code owners
Walkthrough이 Pull Request는 3days API의 OpenAPI 사양에서 인증 및 사용자 등록 섹션의 주요 수정을 포함합니다. SMS 인증 요청 엔드포인트가 Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
| ExistingUserVerifyCodeResponse: | ||
| allOf: | ||
| - $ref: '#/components/schemas/VerifyCodeResponse' | ||
| - type: object | ||
| description: 기존 사용자 인증 응답 | ||
| required: | ||
| - accessToken | ||
| - refreshToken | ||
| - expiresIn | ||
| properties: | ||
| accessToken: | ||
| type: string | ||
| description: 액세스 토큰 | ||
| refreshToken: | ||
| type: string | ||
| description: 리프레시 토큰 | ||
| expiresIn: | ||
| type: integer | ||
| description: 액세스 토큰의 유효 기간 (초 단위) | ||
|
|
||
| NewUserVerifyCodeResponse: | ||
| allOf: | ||
| - $ref: '#/components/schemas/VerifyCodeResponse' | ||
| - type: object | ||
| description: 새 사용자 인증 응답 | ||
| required: | ||
| - registerToken | ||
| properties: | ||
| registerToken: | ||
| type: string | ||
| description: 회원 가입을 위한 토큰 | ||
|
|
||
| RegisterUserRequest: |
There was a problem hiding this comment.
이렇게 하니까 서버쪽에서는 VerifyCodeResponse스키마 에 대한 상속으로 ExistingUserVerifyCodeResponse, NewUserVerifyCodeResponse 두스키마가 잘생성이 되던데, 클라쪽에서는어떤지 한번 확인해주셨으면 합니다 :)
There was a problem hiding this comment.
현재 위 코드로 생성된 VerifyCodeResponse 는
VerifyCodeResponse
ㄴ var responseType: VerifyCodeResponseType
/// - Remark: Generated from `#/components/schemas/VerifyCodeResponseType`.
@frozen public enum VerifyCodeResponseType: String, Codable, Hashable, Sendable {
case EXISTING_USER = "EXISTING_USER"
case NEW_USER = "NEW_USER"
}
즉, 리스폰스로 토큰 등의 필드는 없고 enum 만 들어오도록 되어있는데 의도하신게 맞을까요 ?
There was a problem hiding this comment.
네 VerifyCodeResponse는 ExistingUserVerifyCodeResponse, NewUserVerifyCodeResponse의 부모 클래스로 실제 응답은 VerifyCodeResponse를 사용하는게 아니라, ExistingUserVerifyCodeResponse, NewUserVerifyCodeResponse로 하게 되는데요, swift에서는 생성된 코드가 상속관계로 표현되지 않나요?
There was a problem hiding this comment.
네, ExistingUserVerifyCodeResponse 와 NewUserVerifyCodeResponse 리스폰스가 따로 생성이 되긴 하는데요,
오히려 이 리스폰스 모델이 내부에 VerifyCodeResponse 를 가지는 형태로 생성이 되네요 😢
ExistingUserVerifyCodeResponse -> VerifyCodeResponse 형태입니다 .
There was a problem hiding this comment.
Swift코드 한번 생성해봤는데요, 혹시 VerifyCodeResponse로 먼저 json파싱하고 안에있는 responseType기반으로 두객체중 하나로 분기치는건 어렵나요?
public struct ExistingUserVerifyCodeResponse: Codable, JSONEncodable, Hashable {
public var responseType: VerifyCodeResponseType
/** 액세스 토큰 */
public var accessToken: String
/** 리프레시 토큰 */
public var refreshToken: String
/** 액세스 토큰의 유효 기간 (초 단위) */
public var expiresIn: Int
public init(responseType: VerifyCodeResponseType, accessToken: String, refreshToken: String, expiresIn: Int) {
self.responseType = responseType
self.accessToken = accessToken
self.refreshToken = refreshToken
self.expiresIn = expiresIn
}
public enum CodingKeys: String, CodingKey, CaseIterable {
case responseType
case accessToken
case refreshToken
case expiresIn
}
// Encodable protocol methods
public func encode(to encoder: Encoder) throws {
var container = encoder.container(keyedBy: CodingKeys.self)
try container.encode(responseType, forKey: .responseType)
try container.encode(accessToken, forKey: .accessToken)
try container.encode(refreshToken, forKey: .refreshToken)
try container.encode(expiresIn, forKey: .expiresIn)
}
}
public struct VerifyCodeResponse: Codable, JSONEncodable, Hashable {
public var responseType: VerifyCodeResponseType
public init(responseType: VerifyCodeResponseType) {
self.responseType = responseType
}
public enum CodingKeys: String, CodingKey, CaseIterable {
case responseType
}
// Encodable protocol methods
public func encode(to encoder: Encoder) throws {
var container = encoder.container(keyedBy: CodingKeys.self)
try container.encode(responseType, forKey: .responseType)
}
}
There was a problem hiding this comment.
/// - Remark: Generated from `#/components/schemas/VerifyCodeResponseType`.
@frozen public enum VerifyCodeResponseType: String, Codable, Hashable, Sendable {
case EXISTING_USER = "EXISTING_USER"
case NEW_USER = "NEW_USER"
}
말씀주신대로 파싱�하는 방법이 Best 이고,
위 enum VerifyCodeResponseType 에 response 가 함께 들어오면 가능한데
현재 generator 가 생성해준 코드에는 따로 그런 부분이 없이 단순한 enum 만 생성해주고 끝인지라
현 코드상으로는 리스폰스를 연결할 수가 없네요 😢
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (5)
openapi.yaml (5)
Line range hint
20-41: 인증 관련 엔드포인트 구조 개선 및 스키마 이름 변경 승인인증 관련 엔드포인트를
/auth경로로 이동하고 스키마 이름을 더 명확하게 변경한 것은 좋은 개선입니다. 이는 API의 구조를 더 직관적으로 만들어 줍니다.다만, 응답 설명을 좀 더 구체적으로 수정하는 것이 좋겠습니다:
- description: 인증 요청 성공 + description: SMS 인증 코드 전송 성공 및 인증 ID 발급이렇게 하면 응답의 내용을 더 정확하게 설명할 수 있습니다.
Line range hint
45-69: SMS 인증 코드 확인 엔드포인트 개선 승인인증 코드 확인 엔드포인트의 변경사항들이 일관성 있게 적용되었습니다. 특히 기존 사용자와 신규 사용자를 구분하는 응답 구조는 좋은 개선점입니다.
작은 제안사항으로, 작업 설명을 더 명확하게 수정하면 좋겠습니다:
- description: 발급된 인증 코드 아이디(authCodeId)와 SMS 인증 코드로 인증을 완료합니다. + description: 발급된 인증 코드 아이디(authCodeId)와 SMS 인증 코드로 인증을 완료하고, 사용자 상태(기존/신규)에 따라 다른 응답을 반환합니다.이렇게 하면 이 엔드포인트의 동작을 더 정확하게 설명할 수 있습니다.
Line range hint
86-103: 사용자 등록 엔드포인트 개선 승인사용자 등록 요청 스키마 이름 변경과 응답 스키마를
TokenResponse로 변경한 것은 좋은 개선입니다. 이는 다른 엔드포인트들과의 일관성을 높이고, 클라이언트에게 더 유용한 정보를 제공합니다.응답 설명을 조금 더 구체적으로 수정하면 좋겠습니다:
- description: 회원 가입 성공 + description: 회원 가입 성공 및 인증 토큰 발급이렇게 하면 응답에 토큰 정보가 포함되어 있음을 명확히 할 수 있습니다.
Line range hint
325-404: 인증 관련 스키마 개선 승인새로 추가된 인증 관련 스키마들은 다양한 인증 시나리오를 더 상세하고 유연하게 처리할 수 있게 해줍니다. 특히
VerifyCodeResponse에서 사용자 상태에 따라 다른 응답을 제공하는 구조는 매우 유용합니다.
VerifyCodeRequest스키마에 작은 개선을 제안합니다:VerifyCodeRequest: type: object properties: verificationCode: type: string description: 사용자가 입력한 SMS 인증 코드 (6자리 숫자) pattern: '^\d{6}$' + minLength: 6 + maxLength: 6 required: - verificationCode
minLength와maxLength를 추가하면 정확히 6자리 숫자만 허용한다는 것을 더 명확히 할 수 있습니다.
Line range hint
405-421: 사용자 등록 요청 스키마 개선 승인
RegisterUserRequest스키마는 사용자 등록 과정에서 더 상세한 정보를 수집할 수 있게 해주며, 구조화된 접근 방식을 제공합니다. 이는 API의 기능을 확장하고 더 풍부한 사용자 프로필을 생성할 수 있게 해줍니다.스키마 설명을 조금 더 상세하게 수정하면 좋겠습니다:
- description: 회원 가입 시 필요한 사용자 정보 + description: 회원 가입 시 필요한 사용자 정보 (이름, 프로필, 선호하는 파트너 정보 포함)이렇게 하면 스키마에 포함된 정보의 범위를 더 명확히 할 수 있습니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- openapi.yaml (8 hunks)
🔇 Additional comments (3)
openapi.yaml (3)
Line range hint
104-123: 토큰 갱신 엔드포인트 경로 변경 승인토큰 갱신 엔드포인트를
/auth경로로 이동한 것은 전체적인 인증 관련 엔드포인트 구조 개선과 일치합니다. 이는 API의 일관성을 높이고 더 직관적인 구조를 만듭니다.
Line range hint
224-230: 인증 코드 ID 파라미터 이름 변경 승인
VerificationIdPath에서AuthCodeIdPath로의 변경, 그리고name속성을verificationId에서authCodeId로 업데이트한 것은 적절합니다. 이는 인증 엔드포인트의 변경사항과 일치하며, 파라미터의 목적을 더 명확하게 표현합니다.
Line range hint
1-624: 전체적인 API 스펙 개선에 대한 종합 의견이번 변경사항들은 3days API의 구조, 일관성, 명확성을 크게 개선했습니다. 주요 개선 사항은 다음과 같습니다:
- 인증 관련 엔드포인트를
/auth경로로 통합하여 API 구조를 개선했습니다.- 스키마 이름을 더 명확하고 일관성 있게 변경했습니다.
- 사용자 상태(신규/기존)에 따라 다른 응답을 제공하는 유연한 인증 프로세스를 구현했습니다.
- 사용자 등록 과정에서 더 상세한 정보를 수집할 수 있게 되었습니다.
이러한 변경사항들은 API의 사용성을 높이고, 클라이언트 개발자들이 더 쉽게 이해하고 구현할 수 있게 해줄 것입니다. 또한, 향후 기능 확장에도 유연하게 대응할 수 있는 구조를 갖추게 되었습니다.
제안된 작은 개선사항들(응답 설명 구체화, 스키마 설명 보완 등)을 반영하면 더욱 완성도 높은 API 스펙이 될 것입니다.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
openapi.yaml (3)
Line range hint
20-41: 인증 엔드포인트 변경 승인인증 관련 엔드포인트를
/auth경로 아래로 이동한 것은 API 구조를 개선하는 좋은 변경사항입니다. 새로운 스키마 이름들도 엔드포인트의 목적을 더 잘 반영하고 있습니다.한 가지 제안사항:
SendAuthCodeResponse에 인증 코드의 만료 시간을 추가하는 것이 좋을 것 같습니다. 이를 통해 클라이언트가 사용자에게 남은 시간을 표시할 수 있습니다.
SendAuthCodeResponse스키마에 다음 속성을 추가하는 것을 고려해보세요:SendAuthCodeResponse: type: object properties: authCodeId: type: string format: uuid description: 인증 요청에 대한 고유 식별자 (UUID 형식) expiresIn: type: integer description: 인증 코드의 유효 기간 (초 단위) required: - authCodeId - expiresIn
355-404: VerifyCodeResponse 스키마 개선 승인
VerifyCodeResponse스키마의 변경사항은 기존 사용자와 신규 사용자에 대해 서로 다른 응답을 제공할 수 있게 해주는 좋은 개선입니다. 판별자(discriminator)를 사용하여 다른 응답 유형을 처리하는 것은 좋은 방식입니다.한 가지 제안사항:
ExistingUserVerifyCodeResponse와NewUserVerifyCodeResponse스키마에 공통 필드가 있다면, 이를 기본VerifyCodeResponse로 이동하는 것을 고려해보세요. 이렇게 하면 중복을 줄이고 스키마를 더 깔끔하게 만들 수 있습니다.예를 들어, 만약
expiresIn필드가 두 응답 유형에 공통적으로 사용된다면, 다음과 같이 변경할 수 있습니다:VerifyCodeResponse: type: object discriminator: propertyName: responseType mapping: EXISTING_USER: '#/components/schemas/ExistingUserVerifyCodeResponse' NEW_USER: '#/components/schemas/NewUserVerifyCodeResponse' required: - responseType - expiresIn properties: responseType: $ref: '#/components/schemas/VerifyCodeResponseType' expiresIn: type: integer description: 액세스 토큰의 유효 기간 (초 단위) description: 인증 응답 (기존 사용자와 신규 사용자 모두에 해당) ExistingUserVerifyCodeResponse: allOf: - $ref: '#/components/schemas/VerifyCodeResponse' - type: object description: 기존 사용자 인증 응답 required: - accessToken - refreshToken properties: accessToken: type: string description: 액세스 토큰 refreshToken: type: string description: 리프레시 토큰 NewUserVerifyCodeResponse: allOf: - $ref: '#/components/schemas/VerifyCodeResponse' - type: object description: 새 사용자 인증 응답 required: - registerToken properties: registerToken: type: string description: 회원 가입을 위한 토큰이렇게 하면
expiresIn필드의 중복을 제거하고 스키마 구조를 더 명확하게 만들 수 있습니다.
Line range hint
405-435: 사용자 등록 엔드포인트 개선 승인새로운
RegisterUserRequest스키마는 사용자 등록에 대해 더 구조화된 접근 방식을 제공합니다. 등록 응답에TokenResponse를 사용하는 것은 다른 토큰 관련 엔드포인트와의 일관성을 보장하여 좋은 변경사항입니다.한 가지 제안사항:
RegisterUserRequest에 이메일 주소 필드를 추가하는 것을 고려해보세요. 이는 향후 이메일 기반 기능(예: 비밀번호 재설정, 알림 등)을 위해 유용할 수 있습니다.
RegisterUserRequest스키마에 다음과 같이 이메일 필드를 추가할 수 있습니다:RegisterUserRequest: type: object description: 회원 가입 시 필요한 사용자 정보 properties: name: type: string description: 사용자 이름 email: type: string format: email description: 사용자 이메일 주소 profile: $ref: '#/components/schemas/UserProfile' desiredPartner: $ref: '#/components/schemas/UserDesiredPartner' required: - name - email - profile - desiredPartner이렇게 하면 향후 이메일 기반 기능을 쉽게 추가할 수 있습니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- openapi.yaml (8 hunks)
🔇 Additional comments (4)
openapi.yaml (4)
45-59: SMS 인증 엔드포인트 변경 승인SMS 인증 코드 확인 엔드포인트의 변경사항들이 이전 엔드포인트 수정과 일관성 있게 적용되었습니다. 새로운 명명 규칙은 더 명확하고 일관성 있습니다.
특히
verificationId를authCodeId로 변경한 것은 좋은 개선입니다. 이는 이 ID가 인증 코드와 직접적으로 연관되어 있음을 더 명확히 나타냅니다.
Line range hint
104-122: 토큰 갱신 엔드포인트 변경 승인토큰 갱신 엔드포인트를
/auth/token/refresh로 이동한 것은 이전의 변경사항들과 일관성이 있으며, 인증 관련 엔드포인트를/auth아래로 구성하는 좋은 접근입니다.요청 및 응답 스키마를 그대로 유지한 것은 API의 일관성을 유지하는 데 도움이 됩니다. 이는 기존 클라이언트와의 호환성을 보장하면서도 API 구조를 개선하는 좋은 방법입니다.
Line range hint
224-230: AuthCodeIdPath 매개변수 변경 승인
VerificationIdPath를AuthCodeIdPath로 변경한 것은 이전 엔드포인트 수정사항들과 일관성이 있습니다. 새로운 이름은 매개변수의 목적을 더 잘 반영하고 있어 API의 명확성을 향상시킵니다.설명과 다른 속성들을 그대로 유지한 것은 좋은 접근입니다. 이는 기존 문서와의 일관성을 유지하면서도 필요한 변경을 적용한 것으로 보입니다.
Line range hint
1-653: 전체적인 API 구조 개선에 대한 종합 평가이번 변경사항들은 전반적으로 API의 구조와 명확성을 크게 개선했습니다:
- 인증 관련 엔드포인트를
/auth경로 아래로 이동하여 API의 구조를 더 논리적으로 만들었습니다.- 새로운 스키마들을 도입하여 다양한 사용자 유형에 대한 응답을 더 유연하게 처리할 수 있게 되었습니다.
- 기존 클라이언트와의 호환성을 유지하면서도 API의 전반적인 구조를 개선했습니다.
이러한 변경사항들은 API의 유지보수성과 확장성을 향상시키며, 개발자들이 API를 더 쉽게 이해하고 사용할 수 있게 해줄 것입니다.
향후 고려사항:
- 새로운 구조에 맞춰 API 문서를 업데이트하고, 변경사항에 대한 마이그레이션 가이드를 제공하는 것이 좋겠습니다.
- 성능 모니터링을 통해 새로운 구조가 API의 응답 시간에 미치는 영향을 확인해보세요.
전반적으로 이번 변경은 API의 품질을 크게 향상시키는 훌륭한 개선이라고 평가됩니다.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (5)
openapi.yaml (5)
Line range hint
20-41: 인증 요청 엔드포인트 개선 승인인증 요청 엔드포인트의 변경사항이 전반적으로 잘 구현되었습니다. SendAuthCodeRequest와 SendAuthCodeResponse 스키마를 사용하여 요청과 응답을 명확히 정의한 것이 좋습니다.
다만, 설명을 조금 더 구체적으로 작성하면 좋을 것 같습니다.
설명을 다음과 같이 수정하는 것은 어떨까요?
- description: 회원 가입 또는 로그인을 위한 SMS 인증을 요청합니다. + description: 회원 가입 또는 로그인을 위한 SMS 인증 코드를 요청합니다. 요청 성공 시 authCodeId를 반환합니다.
Line range hint
45-75: 인증 코드 확인 엔드포인트 개선 승인인증 코드 확인 엔드포인트의 변경사항이 잘 구현되었습니다. 특히 기존 사용자와 신규 사용자를 구분하는 응답 스키마의 사용이 인상적입니다.
다만, 응답 설명을 더 명확하게 할 수 있을 것 같습니다.
응답 설명을 다음과 같이 수정하는 것은 어떨까요?
- description: 기존 사용자 인증 응답 + description: 인증 성공 응답 (기존 사용자의 경우 200 상태 코드 반환) - description: 신규 사용자 인증 응답 + description: 인증 성공 응답 (신규 사용자의 경우 201 상태 코드 반환)또한, 각 응답 유형에 대한 스키마 참조를 추가하면 더 명확할 것 같습니다:
content: application/json: schema: - $ref: '#/components/schemas/VerifyCodeResponse' + oneOf: + - $ref: '#/components/schemas/ExistingUserVerifyCodeResponse' + - $ref: '#/components/schemas/NewUserVerifyCodeResponse'
Line range hint
230-236: 인증 코드 ID 파라미터 이름 변경 승인VerificationIdPath에서 AuthCodeIdPath로의 파라미터 이름 변경은 적절합니다. 이는 인증 프로세스의 다른 변경 사항들과 일관성을 유지하며, API 전반에 걸쳐 더 정확한 용어를 사용하고 있습니다.
관련된 문서나 코드 주석도 이 변경사항을 반영하여 업데이트하는 것이 좋겠습니다. 예를 들어, 다음과 같이 설명을 더 명확하게 할 수 있습니다:
- description: 인증 요청 시 발급된 고유 식별자 (UUID 형식) + description: SMS 인증 코드 요청 시 발급된 인증 코드의 고유 식별자 (UUID 형식)
361-377: 인증 코드 확인 응답 스키마 개선 승인VerifyCodeResponseType 열거형의 추가와 VerifyCodeResponse 스키마에 판별자(discriminator)를 사용한 것은 좋은 변경입니다. 이를 통해 기존 사용자와 신규 사용자에 대해 다른 응답 유형을 유연하게 처리할 수 있게 되었습니다.
스키마의 이해를 돕기 위해 예시를 추가하는 것은 어떨까요? 다음과 같이 각 응답 유형에 대한 예시를 추가할 수 있습니다:
VerifyCodeResponse: type: object discriminator: propertyName: responseType mapping: EXISTING_USER: '#/components/schemas/ExistingUserVerifyCodeResponse' NEW_USER: '#/components/schemas/NewUserVerifyCodeResponse' required: - responseType properties: responseType: $ref: '#/components/schemas/VerifyCodeResponseType' description: 인증 응답 (기존 사용자와 신규 사용자 모두에 해당) example: responseType: EXISTING_USERExistingUserVerifyCodeResponse와 NewUserVerifyCodeResponse 스키마에도 각각 적절한 예시를 추가하면 좋겠습니다.
379-410: 사용자 유형별 인증 응답 스키마 추가 승인기존 사용자와 신규 사용자를 위한 별도의 응답 스키마를 추가한 것은 매우 좋은 변경입니다. VerifyCodeResponse를 기반으로 확장하여 각 사용자 유형에 맞는 추가 정보를 포함시킨 것이 인상적입니다.
다만, 각 스키마에 대한 설명과 예시를 추가하면 API 사용자의 이해를 더욱 돕게 될 것 같습니다. 다음과 같이 수정해 보는 것은 어떨까요?
ExistingUserVerifyCodeResponse: allOf: - $ref: '#/components/schemas/VerifyCodeResponse' - type: object description: 기존 사용자 인증 성공 시 반환되는 응답. 액세스 토큰과 리프레시 토큰을 포함합니다. required: - accessToken - refreshToken - expiresIn properties: accessToken: type: string description: 사용자 인증에 사용할 액세스 토큰 refreshToken: type: string description: 액세스 토큰 갱신에 사용할 리프레시 토큰 expiresIn: type: integer description: 액세스 토큰의 유효 기간 (초 단위) example: responseType: EXISTING_USER accessToken: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." refreshToken: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." expiresIn: 3600 NewUserVerifyCodeResponse: allOf: - $ref: '#/components/schemas/VerifyCodeResponse' - type: object description: 신규 사용자 인증 성공 시 반환되는 응답. 회원가입을 위한 임시 토큰을 포함합니다. required: - registerToken properties: registerToken: type: string description: 회원 가입 절차를 완료하기 위한 임시 토큰 example: responseType: NEW_USER registerToken: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."이렇게 하면 각 응답 유형의 목적과 포함된 데이터에 대해 더 명확하게 이해할 수 있을 것입니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- openapi.yaml (8 hunks)
🔇 Additional comments (2)
openapi.yaml (2)
110-110: 토큰 갱신 엔드포인트 경로 변경 승인토큰 갱신 엔드포인트를 /users/token/refresh에서 /auth/token/refresh로 변경한 것은 좋은 결정입니다. 이렇게 하면 인증 관련 엔드포인트들이 /auth 경로 아래에 그룹화되어 API 구조가 개선됩니다.
다만, 이 변경으로 인해 클라이언트 측 코드와 문서를 업데이트해야 할 수 있습니다. 다음 스크립트를 실행하여 이전 엔드포인트 경로를 사용하는 부분이 있는지 확인해 보세요:
#!/bin/bash # Description: 클라이언트 코드와 문서에서 이전 토큰 갱신 엔드포인트 경로 사용 여부 확인 # Test: 이전 엔드포인트 경로 '/users/token/refresh' 검색 rg --type typescript --type javascript --type markdown '/users/token/refresh'검색 결과가 있다면, 해당 부분을 새로운 엔드포인트 경로 '/auth/token/refresh'로 업데이트해야 합니다.
92-92: 사용자 등록 요청 스키마 변경 승인사용자 등록 요청 스키마를 RegisterUserRequest로 변경한 것이 적절해 보입니다. 이는 등록 프로세스나 데이터 요구사항의 변경을 반영한 것으로 보입니다.
다만, 이 변경이 클라이언트 측에 미치는 영향을 확인해 보시기 바랍니다. 다음 스크립트를 실행하여 클라이언트 코드에서 이전 스키마 이름을 사용하는 부분이 있는지 확인할 수 있습니다:
만약 검색 결과가 있다면, 해당 부분을 새로운 스키마 이름 'RegisterUserRequest'로 업데이트해야 합니다.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
openapi.yaml (3)
Line range hint
20-41: 인증 엔드포인트 변경 승인인증 관련 엔드포인트를
/auth경로 아래로 통합한 것은 좋은 API 구조 개선입니다. 새로운 스키마 이름인SendAuthCodeRequest와SendAuthCodeResponse도 엔드포인트의 목적을 잘 나타내고 있습니다.응답 설명을 "인증 요청 성공"에서 "인증 코드 전송 성공"으로 변경하는 것이 어떨까요? 이렇게 하면 응답의 의미가 더 명확해질 것 같습니다.
- description: 인증 요청 성공 + description: 인증 코드 전송 성공
45-68: 인증 코드 확인 엔드포인트 변경 승인인증 코드 확인 엔드포인트를
/auth/codes/{authCodeId}로 변경한 것은 이전 인증 엔드포인트 변경과 일관성이 있어 좋습니다.VerifyCodeRequest스키마 이름도 목적에 잘 부합합니다.기존 사용자와 신규 사용자에 대한 응답을 구분하는 구조는 다양한 시나리오를 처리하는 데 적합한 설계입니다.
응답 구조를 더 명확하게 하기 위해,
VerifyCodeResponse에responseType필드를 추가하고, 이를 통해ExistsUserVerifyCodeResponse와NewUserVerifyCodeResponse를 구분하는 것은 어떨까요? 예를 들면:VerifyCodeResponse: type: object required: - responseType properties: responseType: type: string enum: [EXISTING_USER, NEW_USER] discriminator: propertyName: responseType mapping: EXISTING_USER: '#/components/schemas/ExistsUserVerifyCodeResponse' NEW_USER: '#/components/schemas/NewUserVerifyCodeResponse'이렇게 하면 클라이언트 측에서 응답 타입을 더 쉽게 구분할 수 있을 것 같습니다.
365-392: VerifyCodeResponse 및 관련 스키마 변경 승인
ExistsUserVerifyCodeResponse와NewUserVerifyCodeResponse스키마를 도입한 것은 좋은 변경입니다. 이 구조는 기존 사용자와 신규 사용자에 대해 다른 응답을 제공할 수 있게 해주어 다양한 사용자 시나리오를 더 유연하게 처리할 수 있게 합니다.하지만 기본
VerifyCodeResponse스키마에 명시적인 구분자(discriminator) 속성이 정의되어 있지 않습니다. 다음과 같이VerifyCodeResponse를 수정하는 것이 어떨까요?VerifyCodeResponse: type: object discriminator: propertyName: responseType mapping: EXISTING_USER: '#/components/schemas/ExistsUserVerifyCodeResponse' NEW_USER: '#/components/schemas/NewUserVerifyCodeResponse' properties: responseType: type: string enum: [EXISTING_USER, NEW_USER] required: - responseType ExistsUserVerifyCodeResponse: allOf: - $ref: '#/components/schemas/VerifyCodeResponse' - type: object properties: accessToken: type: string refreshToken: type: string expiresIn: type: integer required: - accessToken - refreshToken - expiresIn NewUserVerifyCodeResponse: allOf: - $ref: '#/components/schemas/VerifyCodeResponse' - type: object properties: registerToken: type: string required: - registerToken이렇게 하면 클라이언트가 응답 유형을 더 쉽게 구분하고 처리할 수 있을 것 같습니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- openapi.yaml (8 hunks)
🔇 Additional comments (6)
openapi.yaml (6)
92-92: 회원 가입 요청 스키마 변경 승인회원 가입 요청 스키마를
RegisterUserRequest로 변경한 것은 적절합니다. 이 이름은 엔드포인트의 목적을 잘 나타내고 있어 코드의 가독성을 향상시킵니다.
110-110: 토큰 갱신 엔드포인트 변경 승인토큰 갱신 엔드포인트를
/auth/token/refresh로 변경한 것은 적절합니다. 이는 이전의 인증 관련 엔드포인트 변경과 일관성이 있으며, API 구조를 더 직관적으로 만들어 줍니다.
230-235: AuthCodeIdPath 파라미터 변경 승인
verificationId에서authCodeId로 파라미터 이름을 변경한 것은 적절합니다. 이는 이전의 인증 엔드포인트 변경과 일관성이 있으며, 파라미터의 목적을 더 정확하게 반영합니다.
Line range hint
331-339: SendAuthCodeRequest 스키마 도입 승인
PhoneNumberRequest를SendAuthCodeRequest로 대체한 것은 좋은 변경입니다. 새 스키마 이름이 엔드포인트의 목적을 더 잘 설명하고 있습니다. 전화번호의 구조와 유효성 검사가 그대로 유지된 것도 적절합니다.
341-349: SendAuthCodeResponse 스키마 도입 승인
RequestVerificationResponse를SendAuthCodeResponse로 대체한 것은 적절합니다. 새 스키마 이름이 요청 스키마 및 엔드포인트의 목적과 더 일관성 있게 되었습니다.verificationId에서authCodeId로의 변경도 이전 변경사항들과 일치하여 좋습니다.
Line range hint
1-392: 전체 API 변경사항 요약이번 PR에서 진행된 API 변경사항들은 전반적으로 API 구조와 명명 규칙을 개선하고 있습니다. 주요 변경 사항은 다음과 같습니다:
- 인증 관련 엔드포인트를
/auth경로 아래로 통합- 요청 및 응답 스키마 이름을 더 명확하고 일관성 있게 변경
- 사용자 유형(기존/신규)에 따른 응답 구조 개선
이러한 변경으로 API의 가독성과 사용성이 향상되었습니다. 몇 가지 minor한 개선 사항을 제안했지만, 전반적으로 변경 사항은 긍정적이며 API의 품질을 높이고 있습니다.
Summary by CodeRabbit
Summary by CodeRabbit
새로운 기능
/auth경로로 재구성되었습니다.버그 수정