주간회고_HTTP 스터디 2회차

배운 것

HTTP 메시지 구조

HTTP 헤더

상태코드

 

회고

책 분량상 메시지 구조와 상태코드가 합쳐서 1 이라면

헤더관련 내용만 2+ 정도 되는 것 같았다.

 

그러나 사실 헤더 관련 내용들이 너무 방대하기도 하고

꽤나 디테일한 내용이 많아서 만족스럽게 소화를 못한 느낌이긴하다.

물론 이런 상황이 나 뿐만은 아닐것이라고 생각한다...

스터디 중간에 나온 얘기지만 현업에서 헤더를 건드려서 작업할 일이 많지 않기 때문이다.

그래도 언젠가는 건드려볼 일이 있을 것이고 자주 마주할 일이 있는 헤더 몇가지는 내용을 잘 숙지하고 있어야 할 것 같다.

 

회사사람 이외의 개발자 분들이랑 얘기를 할 때 마다 느끼지만

다양한 사람들과 소통하는 것이 생각과 눈을 넓히는데 도움이 되는 것 같다.

이번 스터디가 유독 그랬다.

 

먼저 Http 헤더를 커스텀해서 넣을 수 있다는 것을 처음 알았다.

현업에서 헤더를 가지고 뭔가 처리한 경험을 공유해보자고 얘기가 나왔을 때

다국어 처리를 하면서 헤더로 넘어오는 언어 설정을 가지고 i18n 처리를 해보았다는 소박한 경험을 공유했었다.

물론 이때 우리팀이 사용한 헤더는 이미 정의되어 있는 헤더 필드에 있는 값을 보고 처리했었다.

다른 스터디원이 로그인 관련 처리할 때 커스텀 헤더를 추가하여 처리한 경험을 얘기해주셨다.

지금까지는 헤더는 프로토콜에 정의된 것 만 사용을 해야한다 라고 생각하고 있었는데 꼭 그렇지만도 않은것 같다.

나중에 사용할 수 있는 상황이 될 때 이 내용이 떠오르면 좋겠다.

 

나는 이번주에 같이 생각해볼 주제로 "API 응답으로 200 OK로 일관되게 주는 상황"을 제시했다.

지금 회사에 입사하고 나서 다른 팀에서 만든 API를 사용할 때 위와 같은 스펙으로 되어있었다.

통신이 되면 무조건 200 OK로 리턴이 오고 처리중 에러가 있었다면 일관된 커스텀 에러구조로 응답을 주었다.

검색과 나름의 고민을 통해 우선 마음속으로 내린 결론은

"회사 특성상 이렇게 되어있는거고, 이런 방식은 잘 사용하지 않는가 보다" 라는 것이었다. 

그러나 다른 스터디원의 경험을 비롯해 다른 곳에도 이런 방식이 종종 사용되는 것을 알게되었다.

나름의 이유도 있었다. 또한 퍼실리테이터님의 얘기도 생각이 많아지게 하는 부분이 있었다.

어떤 방식을 택하던 정답은 없을 수 있다.
그러나 왜 그런 결정을 내렸는 지에 대해 나의 생각과 근거는 말할 수 있어야 하지 않을까요.

 

물론 정확한 컨텍스트는 아니고;; 말씀해주신 의도도 다를 수도 있다.

나름대로 200 OK로 일관된 상태코드를 사용하는 이유를 다시 정의해 보았다.

우선 API 요청에 대한 통신은 되었으므로 200 OK를 기본적으로 리턴을 한다.
그리고 메시지 내부에서 Http 상태코드 보다도 자세한 커스텀 코드를 리턴하기 위함이다.
클라이언트-서버 사이 약속(프로토콜)이므로 서로 얘기만 된다면 커스텀 에러도 충분히 좋은 방식일 수 있을 것 같다.

 

혼자서 생각하고 끝이었다면 내지 못했을 다른 결론이지만

스터디를 통한 경험 및 의견 공유로 좀 더 폭 넓은 생각을 통해 다른 결론을 내릴 수 있었던 것 같다.

다음주에는 또 어떤 다른 얘기를 나눌 수 있을지 기대가 된다!