분류 전체보기

· Spring
이전 포스팅(공통 형식의 응답 효율적으로 처리하기) 에서 공통응답형식을 RequesetBodyAdvice를 구현한 객체에서 처리하였다. 핸들러메서드(Controller 메서드)에서는 실제 결과 데이터 서빙에만 집중할 수 있어 전체적으로 가독성과 개발 생산성이 높아졌다. 하지만 얼마가지 않아 한 가지 문제가 발생하였는데, 바로 핸들러 메서드에서 문자열 응답시 공통응답형식의 적용이 불가능하다는 점이었다. 문자열 응답에도 RequesetBodyAdvice에서 공통형식이 적용되었다면 적어도 아래와 같은 응답을 받아야 하지만 예외가 발생하였다. { code: 200, message: "Success", data: "문자열 응답"} 이번 포스트에서는 필자가 해당 문제를 해결한 과정을 크게 3 부분으로 나눠 공유해본..
· Spring
'개발 한 스푼' 서비스에서는 다음과 같은 형식으로 응답 Body를 보낸다. 성공과 실패 시 같은 응답형식을 취하고 code와 message를 통해 보다 자세한 실패 이유를 알려주기 위함이다. 추후 추가적인 메타정보를 넘겨줄때도 본 데이터에 섞이지 않고 확장시킬 수 있다. // 성공{ "code": 200, "message": "Success", "data" : { } // 성공시 데이터 // 추가적인 데이터가 들어갈 수도(ex. traceId 등)}// 실패시{ "code": 400_001_003, // 내부적으로 유지하는 실패코드 "message": "뭔가 잘못되었습니다."} 핸들러 메서드에서 매번 같은 형식의 응답객체로 래핑하여 응답하는 것은 반복적인 작업임이 분명하..
· Spring
이전 포스트에서 요청/응답 Body에 포함된 Legacy Enum들을 인터페이스를 이용해 다뤘던 방법을 작성하였다. 아쉽게도, '개발 한 스푼' 서비스에서는 쿼리 파라미터에도 Enum 스타일의 소문자 문자열들이 사용되고 있다. Kotlin에서는 Enum값을 대문자로 작성하는 것을 권장하기 때문에 이에 바인딩하는 작업을 커스텀해야한다.이번 글에서는 RequestParam, ModelAttribute에 포함된 다수의 Legacy Enum들을 효율적으로 관리하기 위해 적용한 방식을 공유해본다.본 포스트는 다음과 같은 수순으로 진행됩니다.1. 기존 Converter 톺아보기2. 구현 방향성과 방법   1. 기존 Converter 톺아보기@RequestParam과 @ModelAttribute 를 통해 쿼리 정보들..
· Spring
사용 가능한 값이 제한되어 있는 경우 Enum을 사용하면 가독성과 사용성을 높일 수 있다. 현재 운영중인 '개발 한 스푼' 서비스의 API 요청/응답 Body에서도 이런 Enum 스타일의 필드가 여럿 존재한다. 문제는 해당 필드값들이 소문자 문자열이라는  것이다. 현재 서버리스 API 서버에서 Spring Boot+Kotlin 서버로 마이그레이션 중인데 Kotlin에서는 Enum값을 대문자로 작성하는 것을 권장한다. 이번 글에서는 Body에 포함되어 있는 다수의 Enum 스타일의 소문자 문자열들(Legacy Enum)을 효율적으로 처리하기 위해 적용한 방식을 공유해본다. 해당 포스트는 다음의 수순으로 진행됩니다.1. 기존 가능한 방식과 문제점2. 방향성 및 해결방법   1. 기존 가능한 방식과 문제점1...