HTTP 상태코드

HTTP 상태 코드란 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능이다. 각 상태 코드마다 의미가 다르다. 요약을 하면 다음과 같은 정보를 가지고 있다.

• 1XX(Informational) : 요청이 수신되어 처리중
• 2XX(Successful) : 요청 정상 처리
• 3XX(Redirection) : 요청을 완료하려면 추가 행동이 필요
• 4XX(Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행 할 수 없음
• 5XX(Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함

만약 모르는 상태 코드가 나왔을 경우 상위 상태코드로 해석해서 처리하면된다. 미래에 새로운 상태 코드가 추가되어도 위에와 같은 형태를 유지 하기 때문에 해석하기 쉬움. 1XX는 요청이 수신되어 처리중을 의미하고 거의 사용하지 않는다. 2XX부터 함께 살펴보자!

 

2XX - 성공

클라이언트의 요청을 성공적으로 처리했다는 코드이다.

1. 200 OK - 요청 성공                                                 2. 201 Created - 요청 성공해서 새로운 리소스가 생성됨

3. 202 Accepted - 요청이 접수되었으나 처리가 완료되지 않았음 -> 배치 처리에서 주로 사용

4. 204 No Content - 서버가 요청으 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

• 예) 웹 문서 편집기에서 save 버튼
• save 버튼의 결과로 아무 내용이 없어도 된다.
• save 버튼을 눌러도 같은 화면을 유지해야 한다.
• 결과 내용이 없어도 204 메시지만으로 성공을 인식 할 수 있다.

3XX - 리다이렉션

요청을 완료하기 위해 유저 에이전트의 추가 조치가 필요하다는 코드이다. 그렇다면 리다이렉션이란 무엇인가? 웹 브라우저는 3XX 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동으로 이동한다. 이를 리다이렉트라고 한다. 예를 통해 살펴보자

만약 클라이언트가 과거 이벤트 url에 접근한다고 하자. 그러면 우리 서버는 새로운 이벤트 url을 보여줘야한다. 먼저 처음 요청에 대해 Location 헤더에 새로운 이벤트 url을 적어서 301 코드로 응답한다. 그렇게 되면 클라이언트는 새로운 url을 통해 재요청을 보내고 정상 200으로 새로운 이벤트 페이지를 보여주게 된다. 리다이렉션은 방금과 같이 특정 리소스의 URI가 영구적으로 이동하는(/event -> /new-event) 영구 리다이렉션과 일시적인 변경(주문 완료 후 주문 내역 화면으로 이동)하는 일시 리다이렉션이 있다.

 

영구 리다이렉션 - 301, 308

• 리소스의 URI가 영구적으로 이동
• 원래의 URL를 사용하지 않음, 검색 엔진 등에서도 변경 인지
• 301 Moved Permanently
  • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거 될 수 있음
• 308 Permanent Redirect
  • 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

 

일시적인 리다이렉션 - 302, 307, 303

• 리소스의 URI가 일시적으로 변경
• 따라서 검색 엔진 등에서 URL을 변경하면 안됨
• 302 Found
  • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거 될 수 있음
• 307 Temporary Redirect
  • 302와 기능은 같음
  • 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다.)
• 303 See Other
  • 302와 가능은 같음
  • 리다이렉트시 요청 메서드가 GET으로 변경

일시적인 리다이렉션에서 문제점이 있다. 만약 POST로 주문후에 웹 브라우저를 새로고침하면 아떻게 될까? 새로고침은 다시 요청하는 것으로 중복 주문이 들어 갈 수 있다. 문제 상황은 다음 그림과 같다.

 

이를 해결하는 방법은  PRG(POST/REDIRECT/GET)을 사용하는 것이다. POST로 주문 후에 새로 고침으로 인한 중복 주문 방지하는 방법으로 POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트한다. 그 이후엔 새로고침을 해도 결과 화면을 GET으로 조회하게 되고 중복 주문 대신에 결과 화면만 GET으로 다시 요청하게 된다.

 

기타 리다이렉션

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

자세한 내용은 캐시때 살펴보자!

 

4XX - 클라이언트 오류

클라이언트의 요청, 잘못된 문법등으로 서버가 요청을 수행 할 수 없는 상태일때 반환한다. 오류의 원인이 클라이언트에 있기때문에 똑같은 재시도를 해도 실패하게됨

• 400 Bad Request
  • 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리 할 수 없음
  • 클라이언트는 요청 내용을 다시 검토하고 보내야함.
  • 예) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때
• 401 Unauthorized
  • 클라이언트가 해당 리소스에 대한 인증이 필요함
  • 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
  • 인증(Authentication) : 본인이 누구인지 확인(로그인)
  • 인가(Authorization) : 권한부여(ADMIN권한 처럼 특정 리소스에 접근 할 수 있는 권한, 인증이 있어야 인가가 있음)
• 403 Forbidden
  • 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
  • 예) ADMIN 등급이 아닌 사용자가 로그인은 했지만, ADMIN 등급의 리소스에 접근하는 경우
• 404 Not Found
  • 요청 리소스가 서버에 없음
  • 클라이언트가 권한이 부족한 리소스에 접글 할 때 해당 리소스를 숨기고 싶을 때 사용하기도 함.

 

5XX - 서버 오류

• 500 Internal Server Error
  • 서버 내부 문제로 오류 발생
  • 애매하면 500 오류
• 503 Service Unavailable
  • 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음