자주 사용되는 Http status code

상황에 따른 HTTP status 코드 사용하기

Rest API 서버를 개발할 때 400 : Bad Request와 200 : OK 만 사용하는 경우가 있는데, 상황에 따라 조금 더 명확한 정보를 전달할 수 있는 HTTP 상태코드를 알아보자.

 

• 1xx(Information) : 요청이 수신되어 처리중이며, 계속해서 프로세스를 진행한다.
• 최근에는 1xx 상태코드를 거의 사용하지 않는다.
• 2xx(Successful) : 요청을 성공적으로 수신했으며, 정상적으로 처리되었다.
• 3xx(Redirection) : 요청을 완료하려면 추가적인 행동(리소스)이 필요하다.
• 4xx(Client Error) : 클라이언트 오류, 잘못된 문법/요청 등으로 서버가요청을 수행할 수 없다.
• 5xx(Server Error) : 서버가 정상 요청을 처리하지 못함

2XX : Information

200 OK

요청이 성공적으로 완료되었으며, 정보를 함께 반환할 수 있다.

201 Created

요청에 성공해서 새로운 리소스가 생성되었다. (주로 회원가입과 같은 새로운 리소스 생성에 많이 사용한다.)

202 Accepted

요청이 접수 되었으나 아직 처리가 완료되지 않았다. (요청 접수 1시간 후 배치 프로세스가 요청을 처리하는 배치 처리에 주로 사용된다. ex)1시간 후 게시글 삭제 예약 )

204 No Content

요청을 성공적으로 수행했지만 응답 페이로드 본문에 보낼 데이터가 없음. 단, 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있음.

ex) 웹 문서 편집기의 save 버튼 : sava버튼을 눌러도 화면상 아무런 변화는 없다. 결과 내용은 없지만 204 상태코드로 해당 작업의 성공을 인식시켜 줄 수 있다.

ex) 리소스의 삭제가 정상적으로 처리되었을 때 사용할 수 있다.

 

3XX : Redirection

기본적으로 웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면 해당 Location 위치로 자동 이동한다.

HTTP/1.1 301 Moved permanently
Location: /new-event

자동으로 /new-event 페이지로 이동한다.

💡 영구 리다이렉션 - 특정 리소스의 URL이 영구적으로 이동한다. (301, 308)301 Moved Permanetly

요청한 리소스의 URI가 변경되었음을 의미한다. URI의 요청 방식이 GET으로 변할 수 있고, 본문이 제거될 수 있다.

308 Permanent Redirect

301과 동일하지만 처음 받았던 요청 방식(get/post 등)을 그대로 유지한다. 본문이 제거될 수 있다.

 

💡 일시 리다이렉션 - 일시적인 변경으로, 실무에서 많이 사용한다.

예를들어, 쇼핑몰에서 주문을 완료하면 주문 내역 화면으로 이동되는 경우가 있다.

만약 리다이렉션을 하지 않고 주문 완료 페이지에 머무르다가 사용자가 새로고침을 하게된다면 ?

최악의 경우 중복 결제가 일어날 수 있다. PRG(post-redirect-get) 순으로 진행되어 GET 요청 결과 하면을 리턴, 중복 주문을 방지할 수 있다.

302 Found

리다이렉트 요청 메소드가 GET 으로 변하고 본문이 제거될 수 있음

307 Temporary Redirect

클라이언트가 요청한 리소스가 다른 URI에 있으며 이전 요청과 동일한 메소드를 사용해서 요청해야 할 때 서버가 클라이언트에 요청을 직접 보낸다. 기존의 요청 메소드(GET/POST 등)는 변경되면 안되며, 본문 또한 유지되어야 함

303 See other

302와 동일한 기능이지만, 명확하게 GET으로 변경해서 리다이렉션 해준다.

(302의 대용으로 등장했으나, 이미 수 많은 프로젝트에서 302를 사용하고 있어서 정확히 어떤 상태코드를 사용해야 한다 라는 정의는 없다.)

💡 특수 리다이렉션 - 결과 대신 캐시를 사용304 Not Modified

캐시를 목적으로 사용한다.

클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용 한다. 또한 304 응답은 바디에 메시지를 포함하면 안된다. (로컬 캐시를 그대로 사용해야 하기 때문에)

4XX : Client

400 Bad Reqeust

가장 많이 사용되는 4xx 에러로 요청 구문 또는 메시지 등의 오류가 있을 때 사용한다. 클라이언트는 요청 내용을 다시 검토후 보내야 한다.

401 Unauthorized

클라이언트가 해당 리소스에 대한 인증이 필요하다. 예를들어 로그인이 필요한 환경에 비로그인으로 접근했을 경우 발생시킬 수 있다.

응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명해서 보낼 수 있다.

403 Forbidden

서버가 요청을 이해 했지만 승인을 거부하는 경우 발생시킬 수 있다. 주로 인증은 완료되었지만, 접근 권한이 불충분한 경우로 예를들어 Admin등급이 아닌 사용자가 로그인(인증)은 완료했지만, Admin 등급 이상 접근 가능한 리소스에 접근했을 경우 발생한다.

404 Not Found

비 개발자도 알고있는 404 Error. 대부분 요청 리소스가 없을때 발생한다.

추가적으로 403과 같이 클라이언트가 권한이 부족한 리소스에 접근했을 경우 페이지를 숨기는 용도로도 가끔씩 사용한다.

409 Conflict

현재 서버의 상태와 충돌했을 때 사용한다. 정확한 정의는 존재하지 않지만, 닉네임이나 아이디 중복의 경우 이미 서버에 존재하는 리소스(닉네임/아이디)와 충돌해서 발생하는 중복 에러를 다루기도 한다.

410 Gone

일시적으로 사용하던 이벤트 페이지(지금은 종료된 이벤트)에 접근했을 때 해당 페이지는 영구적으로 삭제되었다고 알리는 역할을 할 수 있다. 404로 대체 가능해서 잘 사용하지 않는다.

5XX : Sever

5XX에러의 경우 정말 서버에 문제가 있을 경우에만 사용해야 하며, 개발자가 직접 해당 에러들을 리턴하는 경우는 없어야 한다.)

500 Internal Server Error

웹 서버에 문제가 있을 때 발생하는 에러로, 서버에 발생하는 에러의 원인을 정확히 파악하지 못한 경우(애매할 경우) 500으로 처리한다.

503 Service Unavailable

서버가 요청을 처리할 준비가 되지 않았을때 사용한다. 서비스 점검(유지/보수)시 일시적으로 서버의 작동을 중단시킬 때 사용하며 Retry-After : 503(Server Unavailable) 과 함께 사용할 수 있다.

그러나 서버 오류는 대부분 예측이 불가능할 때 나타나기 때문에 503을 볼 일은 거의 없다.

Retry-After : 날짜 표기로, 언제부터 ~ 언제까지 서비스 이용이 불가능한지 표현 가능

 

출처 : https://1-7171771.tistory.com/129?category=972766