HTTP PUT 메서드로 자원을 수정할 때의 응답 : 200 vs 201 vs 202

 수정 메서드를 작성하면서 PUT을 사용하기로 결정한 뒤로 HTTP 응답 상태 코드에 대한 고민은 크게 하지 않았는데, 이번에 해당 기능을 구현하면서 고민을 좀 했다. 200이 맞을까, 201이 맞을까, 아니면 202가 맞을까? 관련해서 상태 코드에 대한 공부도 겸할 수 있었다.

 

 여러 자료와 글들을 읽어보았고, 두 글을 통해 나름대로 해답을 내렸다. 아무튼 수정이 잘 되면 200을 보내는게 맞다.

 

 200은 말 그대로 OK다. 서버에서 '그래그래 형이야. 형은 실제로 클라이언트가 요청한 일을 전부 처리했어.' 라고 하면 200 OK를 보낸다. 이 과정에서 새롭게 생긴 자원이 있으면 안된다. 새롭게 생긴 자원이 있으면 201로 넘어간다.

 

 201은 CREATED다. 일단 앞까지는 똑같다. '그래그래 또 형이야. 형은 또 실제로 전부 처리했어.' 하고 보니 뭔가 만들어진 게 있다? 싶으면 201을 보낸다. '이렇게 전부 처리하고나니 새삼 새롭게 무언가를 또 만들어낸 서버가 문득 대단하게 느껴지네...'의 의미를 내포하고 '나 뭐 만들어냈으니까. 알아둬라'라는 뜻으로 201 CREATED를 보낸다.

 

 여기까지 보면 수정을 완료했을 때 200과 201 중 200을 선택해야함을 판단할 수 있다. PUT은 '대체'하는 메서드다. 기존의 A자원의 모든 값들을 A'으로 대체한다. 대체한다고 새로운 자원이 생기나? 그건 아니다. A -> A'이 될 뿐, B라는 새로운 자원이 생기는 건 아니다. 그래서 200과 201 중 선택하라면 200을 선택해야 한다.

 

 그런데, 202는 어떨까? 202는 ACCEPTED다. 말만 보면 사용자의 요청을 수락했다고 보니 나름 말이 된다. 그런데, 여기에는 한 가지 큰 함정이 있다. 수락했다는 말은 수행했다는 말은 아니다. 실제로 202를 사용해 응답을 보낼 때는 '일단 요청은 수락했는데, 이걸 아직 수행하지는 않았을 때'다.

 

 이렇게 보고 나면 202는 수정이 완료됐을 때 사용하는 것은 부적절해 보인다. 수정 처리가 완료되었는데, 202는 완료하지 않았다는 의미니까 말이다. 그래서 결론은 수정에 대한 응답 상태 코드는 200 OK가 되어야 한다.

 

 그런데 202는 대체 왜 존재할까? 다음에 공부해 볼 내용은 202는 왜 존재하며, 언제 사용하는지 유즈 케이스 탐방으로 정했다.