애매한 HTTP 상태코드 정리

Intro.

실제 프로젝트를 해보니, 예외처리를 하면서 상태코드에 대한 깊은 생각과, 활용법에 대해서 잘 모르고 있다는 생각이 들었다. 실제로 프로젝트에 예외처리와 error response를 적용을 해보려고 하면, 다양한 상태 코드가 제공됨에도 불구하고 제대로 활용하지 못한다.

이렇게 되니까, 클라이언트 쪽에서 요청 에러가 발견 되었을 때, 원인 파악과 조치가 한참 늦어졌다.

이번 포스팅에서 상태코드에 대해서 자세하게 알아보자.

 

상태 코드란 무엇인가?

상태 코드는, 클라이언트에게 요청에 대한 트랜잭션 결과를 이해할 수 있는 쉬운 방법으로 알려준다.

다음은 위키백과에서 가져온 상태코드의 대략적인 정보이다.

• 1xx (정보): 요청을 받았으며 프로세스를 계속한다
• 2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다
• 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다
• 4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다
• 5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다

상태코드를 잘 활용하면, 다음과 같은 이점이 있다.

• 개발 단계에서의 빠른 디버깅
• 클라이언트에게 정확한 의사전달

사유 구절?

사유 구절은 해당 상태코드에 대한 간단한 내용을 포함한다.

Continue, OK, Created, No Content, Internal Server Error 등.

 

이 글에서는, 다음과 같은 형태로 설명한다.

 

상태코드(사유구절) : 설명

• 예시 또는 상세설명

---

어떤 상태코드를 던져줘야할까?

각 상태코드별로, 어떤 경우에 어떤 상태코드를 던져야 하는지 살펴보자.

1xx (정보)

100번대 요청은, 클라이언트에 다음 요청에 대한 힌트를 준다고 생각하면 좋을 것 같다.

상세 코드들과 예시를 살펴보자.

100(Continue): 클라이언트에게 추가적으로 이어서(continue) 요청을 받을 때 사용된다.

유의해야 할 점은, 이 추가적인 요청에 대한 결정은, 서버가 내리는 것이다. 만약 서버가 어떤 결정을 내리던 간에, 클라이언트에서 어짜피 보낼 데이터였다면, 이 100번대 상태코드를 던지면 안된다. 즉 해당 요청들이 연속적이되, 매 요청의 순간마다 서버가 판단하고 서버→클라이언트 방향으로 요청을 하는 것이다.

• (클라이언트)아이디를 입력 → (서버)가입된 아이디인지 확인 후 100번 응답 → (클라이언트) 비밀번호 입력

101(Switching Protocols) : 클라이언트의 요청으로 인해, 서버가 프로토콜을 변경함.

 

2xx (성공)

대부분의 서비스에서, 대부분의 요청들은 성공한다.

단순히 요청을 성공했다는 것을 넘어서, 어떤 부분에 있어서 성공했는지에 대해서 세분화한다.

상세 코드들과 예시를 살펴보자.

200(OK) : 클라이언트가 요청한 데이터를 본문에 담아서 응답함.

• GET URL/main 요청에 대한 응답으로 메인페이지 html을 응답.
• GET URL/post?id=245 요청에 245번 게시글의 내용들을 응답.

201(Created) : 서버 내부에서 객체를 새로 생성하거나, 값에 대한 추가가 일어남.

• POST URL/post 요청으로, 새로운 편지를 생성.
• PATCH URL/user/password요청으로, 유저의 비밀번호를 변경.

204(No Content) : 새로운 페이지로 이동하지 않고, 값을 갱신. 응답에 body 내용이 없다. 기본적으로 캐싱을 제공한다.

• PUT URL/post/autosave 요청으로, 자동저장한 내용을 서버에 갱신해주지만, 페이지 이동도 없으며, 서버에서 값을 새롭게 받지도 않음.

206(Partial Content) : 부분 혹은 범위 요청에 대한 성공.

• Content-Range 헤더를 포함해야한다.
• GET URL/video?id=12030 요청과 Content-Range 헤더를 통해 12030번 비디오의 특정 부분을 요청하고 응답한다.

 

3xx (리다이렉션)

리다이렉션(redirection) : 클라이언트가 관심있어 하는 리소스에 대한 URL을 알려준다.

300(Multiple Choices) : 선택 가능한 여러개의 resource 가 존재할 때.

• GET URL/aboutus 페이지로 이동했을때, 만약 회사 소개가 여러 언어로 번역이 되어 있을 수 있다. 이런 경우, 선택 가능한 여러개의 redirect URL을 주며, 브라우저와의 협상을 통해 적절한 페이지로 이동한다.

301(Moved Permanently) : 요청한 URL 이 옮겨짐.

• GET URL/post/v1/id=245 요청에 대해, 게시판이 리뉴얼되어 옮겨졌으니 new-post로 요청하라고, GET URL/post/v2/id=245 를 Location 헤더에 넣어서 보내준다. 이렇게 되면, 브라우저는 자동으로 v2 로 이동하며, 유저가 따로 접속을 하기 위해 추가적인 동작을 하지 않아도 된다.

302(Found) : 임시로 다른 URL을 사용.

• Oauth2 카카오 로그인 시, account.kakao.com 의 로그인 페이지로 이동하는데, 이것이 임시 URL이다. 결국 여기에서 로그인이 완료되면, 이후의 요청에서는 원래의 URL을 사용해야한다.

💡 의문점 : 블로그에서 글을 작성하고 "작성완료" 버튼을 눌렀을때, ‘게시글 작성창’ → ‘해당 게시글 읽기 페이지’ 이동하는데, 어떻게 처리를 해야하는가?

• 201(새로운 리소스 생성)과 함께, body로 url 응답 후 프론트에서 페이지 이동 처리 (windows.location.href=”URL”)
• 서버에서 바로 3xx응답과 함께 redirect URL을 제공해서 이동 처리

팀원 및 선배님(현 직장인)들과의 의논 결과 = 첫번째 방법

• 서버에서 redirect를 하면, api를 재사용성이 떨어짐
• 백, 프론트를 나눠놓은 형태라서, 프론트의 동작은 프론트에게 위임하는게 이상적
• 300번대 응답이 오면, 브라우저가 헤더를 보고 자동으로 페이지를 이동함. 그래서 응답 후에 프론트에서 추가적인 로직이 있다면, 처리가 까다로움

 

4xx (클라이언트 에러)

클라이언트에서 잘못된 요청을 보냈을때 400번대 에러를 반환한다.

400(Bad Request) : 클라이언트가 잘못된 요청을 보냄.

401(Unauthorized) : 인증 실패.

• POST /login/local 으로 로컬 로그인 요청 했는데, 패스워드가 틀림.
• 세션이 유효하지 않음.

403(Forbidden) : 요청이 서버에 의해 거부됨

• 보안상 위협이 될 수 있는 요소라서, 자세한 내용을 숨기고 싶을때.

404(Not Found) : 요청한 url 찾을 수 없음

• 오타로 GET URL/posst/lisstt 요청을 보냈을 때.
• GET URL/post?id=4423 요처을 날렸는데, 4423 포스트가 존재하지 않음.

405(Method Not Allowed) : 잘못된 매서드 사용

• 로그인 요청을 POST로 구현이 되어있는데, GET URL/login/sns/kakao 같이 요청을 한 경우

406(Not Acceptable) : 엔티티(파라미터 or body) 불일치

• 포스트 id가 쿼리 파라미터로 필요한데, GET URL/post 형식으로 필요한 id를 빼먹은 경우
• 새 게시글 작성을 위해 POST URL/post 요청을 보냈으나, { title: }을 body에 포함하지 않음.

 

5xx (서버 에러)

500(Internal Server Error) : 서버 내부 에러 발생

• 서버 구현 시, nullpointerexception 발생할 때.. ㅠㅠ
• 각종 예외처리 되지 않은 알 수 없는 에러들이 모두 500 에러가 발생한다.

501(Not Implemented) : 브라우저가 요청하는 것이, 표시하지 않도록 설정되어 있음.

502(Bad Gateway) : 요청한 서버가, 다른 서버간의 통신에서 실패

• 게시글 정보를 요청했는데, DB 서버 커넥션이 끊김.
• 카카오 API 로그인을 시도했으나, 카카오 서버가 터져서 연결 불가.