👻 Description
#2 - 📢 API 공통 응답 포맷 에서 설명했듯이,
초기에는 svelte 초보인 나 자신을 위해서 프론트에서 다룰 응답 데이터 포맷을 통일한다는 이유로
이전에 Moyoy 프로젝트를 하면서 맞췄던 커스텀 응답 구조를 그대로 차용해서 구현했었는데요.
프론트는 일단 바이브 코딩으로 하고 있는데다가 구조에 좀 문제가 있었다는 걸 깨닫고 변경하기로 했습니다.
지금 보면 구현도 잘못되어있는 걸 확인할 수 있는데,
Spring에서는 ResponseEntity를 활용해 Response.ok()로 감싼 형태로 body에 status를 넣어줘서 문제 x
그러나 지금 구조에서는 status는 동적으로 변하는데, 포맷 구조는 고정된 형태라 문제가 발생하게 되는데요.
예를 들어 204가 status인 경우에도 body가 그대로 유지되니, RFC 7231를 위반하게 됩니다.
(자세한 내용은 https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.5 참고)
어차피 초기 계획과 다르게 제가 프론트 전체를 손수 한땀한땀 만드는 게 아니기 때문에,
응답 구조 전체를 RESTful 하게 싹 바꿔버리기로 했습니다.
☑️ Todo List (Optional)
👻 Description
#2 -
📢 API 공통 응답 포맷에서 설명했듯이,초기에는 svelte 초보인 나 자신을 위해서 프론트에서 다룰 응답 데이터 포맷을 통일한다는 이유로
이전에 Moyoy 프로젝트를 하면서 맞췄던 커스텀 응답 구조를 그대로 차용해서 구현했었는데요.
프론트는 일단 바이브 코딩으로 하고 있는데다가 구조에 좀 문제가 있었다는 걸 깨닫고 변경하기로 했습니다.
지금 보면 구현도 잘못되어있는 걸 확인할 수 있는데,
Spring에서는
ResponseEntity를 활용해Response.ok()로 감싼 형태로 body에status를 넣어줘서 문제 x그러나 지금 구조에서는 status는 동적으로 변하는데, 포맷 구조는 고정된 형태라 문제가 발생하게 되는데요.
예를 들어
204가 status인 경우에도 body가 그대로 유지되니, RFC 7231를 위반하게 됩니다.(자세한 내용은 https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.5 참고)
어차피 초기 계획과 다르게 제가 프론트 전체를 손수 한땀한땀 만드는 게 아니기 때문에, 응답 구조 전체를 RESTful 하게 싹 바꿔버리기로 했습니다.
☑️ Todo List (Optional)