Skip to content

[gateway] 서비스 응답과 게이트웨이 오류의 공통 응답 형식 래핑 - #16

Open
jyx-07 wants to merge 3 commits into
feat/gateway-circuit-breaker-statusfrom
feat/gateway-response-wrapper
Open

jyx-07 wants to merge 3 commits into
feat/gateway-circuit-breaker-statusfrom
feat/gateway-response-wrapper

Conversation

@jyx-07

@jyx-07 jyx-07 commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

개요

서비스의 JSON 응답과 게이트웨이가 만드는 오류를 모두 {status, code, message, data} 공통 형식으로 맞춥니다.

본문

  • ApiResponseWrapperFilter가 NettyWriteResponseFilter 직전에 서비스 JSON 응답을 감쌈 (성공은 data, 오류는 원본 code·message 사용)
  • 이미 감싼 응답, 비JSON, 압축, 204·304, HEAD, WebSocket, actuator·fallback·Swagger 경로는 그대로 전달
  • 1MB 넘는 응답은 모으다가 원문 그대로 흘려보냄, 감싼 경우 Content-Length 재계산과 ETag 등 제거
  • 게이트웨이 오류 형식 ErrorResponse {code, message}를 CommonApiResponse로 교체

#10 → #12 → #13 → #14 → #15 → 이 PR 순서로 머지해 주세요. 클라이언트가 받는 응답 형식이 바뀌므로 프론트 확인이 필요합니다.

@jyx-07 jyx-07 added breaking-change 호환성을 깨는 변경 ✨ Feature 신규 기능 labels Nov 3, 2026
@github-actions
github-actions Bot requested a review from cfcromn November 3, 2026 09:02
@jyx-07
jyx-07 force-pushed the feat/gateway-response-wrapper branch from 9eb3826 to ed72d9c Compare November 3, 2026 14:14
@jyx-07
jyx-07 changed the base branch from develop to feat/gateway-circuit-breaker-status November 3, 2026 14:14
@jyx-07
jyx-07 added this pull request to stack #20 November 3, 2026 14:18
@jyx-07
jyx-07 force-pushed the feat/gateway-response-wrapper branch from ed72d9c to 84caeed Compare November 3, 2026 14:19

@cfcromn cfcromn left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

래핑 전후로 원본 값이나 HTTP 응답의 의미가 달라지는 경우 두 가지를 확인했습니다.

status: HttpStatus,
body: ByteArray,
): ByteArray? {
val node = if (body.isEmpty()) null else runCatching { objectMapper.readTree(body) }.getOrElse { return null }

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

서비스에서 1234567890.123456789를 반환하도록 테스트했는데, 게이트웨이를 거치면 1.2345678901234567E9로 바뀝니다. 표기뿐 아니라 실제 숫자 값도 달라져서 금액처럼 정밀도가 필요한 데이터에 영향이 있을 것 같아요. 소수를 BigDecimal로 읽도록 설정하고, 래핑 전후의 값이 유지되는지도 테스트해 보면 어떨까요?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cfcromn b007549 에서 반영했습니다. (근거: Jackson USE_BIG_DECIMAL_FOR_FLOATS) 소수를 BigDecimal로 읽고 끝자리 0 제거도 꺼서 원문 숫자가 그대로 유지됩니다. 1234567890.123456789와 1.50이 래핑 후에도 같은지 테스트를 추가했습니다.

excludedPatterns.any { it.matches(pathContainer) } -> Decision.SKIP_EXCLUDED_PATH
requestHeaders.upgrade.equals("websocket", ignoreCase = true) -> Decision.SKIP_WEBSOCKET
method == HttpMethod.HEAD -> Decision.SKIP_NO_BODY
status == HttpStatus.NO_CONTENT || status == HttpStatus.NOT_MODIFIED -> Decision.SKIP_NO_BODY

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

206 부분 응답도 여기서 제외하는 게 좋겠습니다. 7바이트짜리 JSON 응답으로 확인해 보니 래핑 후 본문은 96바이트가 됐는데 Content-Range: bytes 0-6/20은 그대로 남았습니다. 범위 정보가 원본 본문 기준이라, 206이나 Content-Range가 있는 응답은 그대로 전달하는 쪽이 맞을 것 같습니다.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cfcromn b007549 에서 반영했습니다. (근거: RFC 9110 §14.4, Content-Range는 원본 표현 기준) 206 응답이나 Content-Range가 있는 응답은 감싸지 않고 그대로 전달합니다. 정책 단위 테스트와 통합 테스트를 추가했습니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breaking-change 호환성을 깨는 변경 ✨ Feature 신규 기능

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants