POST 요청의 응답에 변경된 데이터를 포함하시나요?

Question

오늘 회사에서 React로 개발을 하다가 궁금한 점이 생겼습니다. 지금은 post 요청을 보내면 응답에 대한 상태와 result 메시지가 응답으로 와요(e.g. ok, 처리 되었습니다.).

이러한 성공 여부만 알 수가 있어서, 새로운 데이터가 생성될 때마다 리페치 함수를 따로 만들어 get 요청을 했습니다. 그런데 가만히 생각해 보니 응답에 변경된 새로운 데이터가 포함돼서 오면 좋을 것 같더라구요.

이렇게 되면 통신 요청수도 줄어들고, 최신 상태를 알 수 있어서 리페칭 할 필요 없이 리렌더링도 할 수 있겠다.라고 생각을 했고, 코드도 더 깔끔하게 만들 수 있을 것 같더라구요.

그런데 이게 아무래도 백엔드에 추가 작업이 들어가는 거라 쉽게 요청을 드리기도 고민이 되었고, 뭔가 모를 찜찜함에 프론트엔드 오픈채팅방에 여쭤보았습니다. 와..근데 답변을 주신 모든 분들이 저처럼 get으로 처리를 하시더라구요. 다들 post 응답 바디의 데이터를 사용하는 데에 부정적인 생각은 없지만, post는 생성에, get은 데이터를 조회하는 것에 대한 역할을 더 중요하게 생각하시는 것 같았습니다.

따라서 현재 제 생각은 클라이언트에서 처리를 하고, 좀 더 메서드의 역할에 맞게 get으로 데이터를 조회하는게 맞다고 생각해요. 그런데 만약 처음부터 응답에 변경된 데이터가 포함되었다면, 그걸 사용했을 것 같단 생각이 들어요.

그래서 더 다른분들의 의견이나 경험을 알고 싶습니다. 제가 모르는 장단점에 대해서 좀 더 알고 싶어요! 혹시 여러분들은 어떻게 처리하시고, 해당 내용에 대해 어떻게 생각하시나요?

Accepted Answer

Method의 역할이 아닌 데에터베이스의 Consistency 관점에서 이야기를 드려볼게요. 
사실 대부분의 경우에 Create / Update operation에 대해서 생성된 resource를 응답에 포함하지 않고 성공 여부만 반환하는 구현은 “틀린 구현” 입니다. 
“틀린” 이라는 단정적인 표현을 사용하기 위해선, 상황 정의를 명확하게 해야겠지요? 제가 정의하는 상황은 단일 서버가 아닌 여러 서버가 동작하는 분산시스템에서의 상황입니다.
그렇다면 분산 시스템에서 위와 같은 구현은 왜 틀렸다고 할 수 있을까요? 이를 이해하기 위해서는 데이터베이스의 Consistency에 대해서 먼저 이해해야 합니다.
Consistency란 간단히 말해서, 내가 방금 수행한 write작업이 read될 수 있는 상황이 되기까지 지연이 있을수 있다는 의미입니다. 다르게 말하면, 내가 방금 insert한 row를 바로 이어서 select를 하면 없는 row라는 결과가 나올 수 있다는거죠. 
이는 데이터베이스가 scalable한 읽기 성능을 제공하기 위해 하는 선택입니다. 많은곳에서 빠르게 읽기 요청 들어온다면 단일 서버에서 감당하기 힘들어집니다. 이럴때 데이터베이스 복제본을 만들어 읽기 서버를 확장하는데요. 이를 읽기 서버의 수평 확장 이라고 하고, 읽기 서버들은 복제본이기에 쓰기 서버에서의 변경이 읽기서버에 반영되기까지 지연이 될 수 있습니다. 이를 흔히 Replication Lag이라고 하죠. 
여기서 RDBMS만 접해보신 분들은 위 내용이 이해가 되지 않을 수 있습니다. 방금 insert한 데이터 select하면 항상 잘 나오는데? 라고 생각하실 수 있죠. 하지만 그 경우는 쓰기서버에 insert / select하는 경우에만 성립합니다. 만약 insert를 한 이후 읽기 서버에 select를 하면 lag으로 인해 데이터가 없을 수 있죠. 이는 매우 흔하게 일어나는 일입니다. 
반대로, 모든 상황에서 쓰기 직후 읽기를 보장한다면 ’Strong Consistency를 지원한다‘ 라고 합니다. 
많은 분산 데이터베이스는 기본적으로 Strong Consistency를 지향하지 않습니다. 즉, 위와 같은 읽기 지연은 매우 일반적이라는거죠. MongoDB나 Cassandra, DynamoDB등의 서버 또한 Quorum(정족수)를 어떻게 설정하냐에 따라서 Strong consistency를 지원할수도, 하지 않을수도 있죠. 하지만 대부분 Consistency를 포기하고 가용성을 지향하게 설정합니다. 
RDBMS를 사용하는 경우 서비스의 성장에 따라 Read Replica를 추가하는 경험을 많이들 하실겁니다. 이 또한 Consistency를 포기하고 데이터베이스를 분산 데이터베이스로 만드는 작업의 일종이죠.

다시 Create / Update 요청과 Get 요청의 주제로 돌아와봅시다. 분산 데이터베이스를 사용한다면 당연히 Get 요청은 읽기 서버에 요청하게 될겁니다. 이 경우 직전에 있던 수정사항이 반영이 안되어있을 확률이 있습니다. 99.999%의 Consistency를 제공하더라고 10만번에 한번은 없을 수 있는거죠. 
이것을 해결하는 올바른 방법은 두가지가 있습니다.

1. Create / Update 요청에서 응답에 변경된 리소스를 담아준다. 
2. 이벤트 기반 설계를 적용하여 생성 결과가 모든 서버에 전파되면 클라이언트에게 이벤트를 푸시해준다.

질문자님의 케이스에는 1번이 정답인거죠.

그렇다면 Strong Consistency를 사용하는 환경, 즉 Read Replica 없이 단일 RDBMS를 사용하는 경우라면 결과에 리소스를 담지 않아도 될까요?
제 의견은 No입니다. 이유는 다음과 같아요. 
1. 지금은 Read Replica가 없어도 언제가 추가될 수 있습니다. 작은 습관으로 큰 수정을 막을 수 있어요. 
2. 어떤 곳에서는 리소스를 담아서 내려주고 어떤곳에서는 안담아주고 하는식으로 일관성 없는 설계를 할 필요가 없습니다. 리소스를 담아서 응답을 주는 방식으로 통일해두는게 API를 읽는 입장에서도 좋습니다.

작성자님은 프론트엔드 엔지니어이시지만 백엔드 엔지니어링 관점에서 이야기를 드리면, 백엔드 시스템 디자인은 분산시스템 설계의 한 분야입니다. 항상 내서버, 데이터베이스, 의존하는 컴포넌트가 분산 환경에서 운영될 수 있다는것을 가정해야하죠.

작성자님이 제안하신 방향이 백엔드 엔지니어링 관점에서 옳은 방법이니 위와 같은 내용으로 팀을 설득해 보시면 좋을 것 같아요.

위에 이야기한 분산 데이터베이스 대해서 더 자세히 알고싶으시다면 다음과 같은 내용을 공부해보세요.

- CAP Theorem
- MySQL Replication
- Cassandra DB
- Raft 합의 알고리즘

권혁진 · Answer

각 http 메소드 마다 역할이 있고

그 역할을 명확히 구분해줘서 설계하는게 좋을것 같습니다

Post 면 데이터를 insert 하고 그 insert 하는 작업의 결과를 응답해주는 도메인 범위가 명확한
api를 설계하는게 좋다고 생각합니다

질문자님이 하고계신대로 따로따로 post, get 요청 하시는게 좋을것 같아요

백승훈 · Answer

저희 프로젝트에서 이번에 10년정도 이전에 개발된 백엔드 서버와의 통신도 겸하고 있는데 post에 ok를 줘도 get시 서버에 데이터에 반영이 안되는 경우가 있더라구요.. 😥

심지어 post에 ok임에도 서버 내에서 실패하는 경우도 있는지 영영 바뀌지 않는경우도.. 이런 경우에도 get으로 실제 반영이 됬는지 이중 체크하는 의미로 생각하면 분리 하는 것이 좋다고 생각합니다

판도라 · Answer

제가 큰 경험이 많다거나 실력이 막 월등하다거나 하는것은 아니지만,

일반적으로 HTTP 메서드의 그 의미에 충실하려고 하고 있습니다.

POST 의 경우는 따로 응답 body를 내리지 않고 HTTP status code, 혹시 오류가 났을 때는 에러메시지 정도를 리턴하는 것 같습니다.

잘못해서 serialize step을 잘못 설계하거나 미처 생각하지 못했을 경우에는 괜히 민감한 데이터가 같이 리턴될까 싶어서요.

그 POST 리퀘스트 이후에 GET 을 만약 또 호출해서 같은 정보를 가져오는 UI/UX가 있다면 프론트 개발자분들과 협의 후에 유동적으로 응답을 조절하게 설계했었습니다.

minw · Answer

만약 다른 플로우에서 그 post를 호출해야 하는 경우가 생기면 어떻게 될까요? 그 플로우에서는 업데이트된 내용이 전혀 필요하지 않을 수도 있고 반대로 좀더 많은 데이터가 필요할 수도 있겠죠
현재로 보면 response에 필요한 값을 추가하는 것이 효율적으로 보일수 있겠지만 역할(기능)이 섞여버리게 되면 서비스의 기능이나 범위가 확장됨에따라 오히려 발목을 잡을 수도 있을껍니다

우리는 서비스가 언제 어떻게 변화할지 알수없기 때문에 가능한 역할에 맞는 기능들을 구성해 두고 이를 이용하도록 해야하지 않을까 싶습니다

nexter · Answer

경우에 따라 다르겠지만 넣은
데이터 그대로 insert 되고, get할때 와 동일한 스키마 형태인 경우, 200응답이 오면 프론트에서 get할때
값을 이미 가지고 있을테니 바로 화면에 표출하면 될수도 있어요.

slowhand · Answer

그래서 Rest를 우리가 정말 잘 사용하고 있느냐에
대답을 YES라고 할 수 없는게 이런 부분이라고 생각하는데요~

생성된 URL을
헤더의 Location으로 지정해서 응답할 수 있겠습니다!

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201

저는 그때그때 마다 다른데
생성 이후 생성된 URL로 이동해야 하는 비즈니스
로직이 있는 Post API call을 하는 경우 응답을 줍니다.
사실 이때도 header로 주지 않고, body로 응답하는것도
조금 생각해볼 필요가 있네요.

네!st · Answer

프론트 단에서 데이터를 캐싱할 수 있다면 reponse로 값을 주는게 좋구요. 
그게 아니라면 성공, 실패에 대한 reponse만 주고 데이터를 get하는 api를 콜해서 UI를 refresh 하는 방법이 좋습니다.