HTTP - HTTP 응답 상태코드 1

들어가며

• 이전 포스트에서 HTTP에 대한 요청(Request)을 할 때 사용하는 HTTP 메서드에 대해 알아보았다.
• 이번 포스트에서는 HTTP 요청 메시지에 대해 서버가 처리를 수행하고 난 뒤 클라이언트에게 전송하는 응답(Response)을, 그 중에서도 상태 코드에 대해 알아본다.

HTTP - HTTP 메서드 활용

 

 

 

상태 코드(Status Code)

• 상태 코드는 클라이언트가 서버에게 요청을 전송한 뒤 서버에서 해당 요청을 받고, 요청의 처리 상태에 대해 현재 어떤 상태인지를 클라이언트에게 알리기 위해 사용하는 코드이다.
• 상태 코드는 크게 5개로 분류되고, 숫자로 표현되며 3자릿수 코드이다.
  • 1XX : 해당 번호대의 코드는 요청이 수신되어 현재 서버에서 처리중일때 반환되는 코드이다.
  • 2XX : 해당 번호대의 코드는 요청이 수신되어 서버에서 정상적으로 처리되었을 때 반환되는 코드이다.
  • 3XX : 해당 번호대의 코드는 요청을 수신했으나 해당 요청을 완료하기 위해서는 추가적인 행동이 필요할 때 반환되는 코드이다. 보통 리다이렉션(redirection)을 수행해야 할 때 사용된다.
  • 4XX : 해당 번호대의 코드는 요청을 서버로 전송할 때 클라이언트의 잘못으로 인해 잘못된 요청을 받고, 서버가 해당 요청을 수행할 수 없을 때 반환하는 코드이다.
  • 5XX : 해당 번호대의 코드는 서버에서 장애가 생겨 클라이언트의 요청을 정상적으로 처리할 수 없을 때 반환하는 코드이다.
• 4XX와 5XX는 장애를 나타내는 코드인데 차이점은 4XX대 코드는 클라이언트에서 서버로 잘못된 요청을 전송하였을 때 사용되는 코드이고, 5XX는 서버가 정상적인 상태가 아니어서 정상적인 요청을 받을 수 없을 때 사용된다.
• 이렇게 각 번호대별로 사용되는 상황을 지정해줌으로서 추후에 새로운 상태 코드를 사용해야 할 때도 문제 없이 확장이 가능하다.(각 번호대별로 00 ~ 99 까지 100개의 코드를 확장시킬 수 있다.)
  • 예를 들어 287번 상태코드가 클라이언트에게 반환되더라도, 클라이언트는 해당 상태코드의 앞번호가 2라는 점에 주목하여 자신의 요청이 일단 서버에 잘 들어갔고, 잘 처리되었다는 것을 알 수 있다.

 

 

 

상태 코드별 설명

2XX(Successful)

• 요청이 성공적으로 서버에서 처리되었다는 것으로 200, 201, 202, 204가 있다.
• 200은 OK로 말 그대로 요청이 성공적으로 처리되었을 때 서버에서 반환하는 코드이다.
• 201은 Created로 해당 요청으로 인해 새로운 리소스가 서버에 생성되었을 때 반환하는 코드이다.
  • 만약 회원 등록의 POST요청이 성공적으로 서버에서 처리되었다면 201이 반환될 것이다.
  • 이때 생성된 리소스는 응답 헤더의 Location으로 식별이 가능하다.
• 202는 Accepted로 요청이 접수는 되었으나 아직 처리가 완료되지 않은 상태일 때 반환하는 코드이다.
  • 요청을 모아두다 한번에 처리하는 배치 처리같은 서비스에서 사용된다.
• 204는 No Content로 서버가 요청을 성공적으로 처리하였으나 클라이언트로 보낼 데이터가 없을 때 반환하는 코드이다. 
  • 예를 들자면 웹 문서 편집기, 더 구체적으론 이런 티스토리 같은 문서 작성에서 저장 버튼을 눌렀다고 생각해보자.
  • 저장 버튼을 눌렀다고 해서 그 결과로 무언가 나오는 것은 우리는 원치 않는 동작이다. 그냥 현재 적어놓은 문서가 그대로 저장되어 있기만을 원하지 다른 창으로 이동하거나, 어떠한 내용이 전송되는건 필요하지 않다.
  • 이럴 때 저장 요청이 성공했는지는 어떻게 판단해야 하는가에 대한 해결책으로 어떤 내용이나, 화면을 지속적으로 유지해야 하면서도 요청의 성공 여부를 판단해야 할 때 해당 코드를 사용한다.

3XX(Redirection)

• 요청을 완료하기 위해 클라이언트의 추가적인 조치가 필요한 상태일때 반환하는 코드이다.
• 일반적으로 리다이렉션(Redirection)을 처리해야할 때 사용되는데 먼저 리다이렉션의 개념부터 인지해보자. 

Redirection

• 리다이렉트는 어떠한 위치로 자동적으로 이동하는 것으로 웹 브라우저는 응답으로 3XX 상태코드를 수신했을 때, Location 헤더가 존재하면 해당 위치로 자동으로 이동한다. 즉 해당 위치로 리다이렉트 한다.
• 리다이렉션의 과정은 다음과 같이 일어난다.
  • 먼저 클라이언트가 어떤 페이지에 대해 요청을 보낸다고 가정하자. 클라이언트가 요청을 보내어 받고 싶은 데이터는 /event에 존재하는 리소스이다.
  • 서버는 해당 요청을 받았다. 그런데 해당 리소스는 다른 곳으로 영구적으로 이동한 상태이다(moved permanently) 따라서 클라이언트가 이동한 곳으로 추가적인 동작을 수행할 필요가 있다.
  • 서버는 이에 301(Moved Permanently)상태코드를 반환하고, 응답 메시지의 Location 헤더에 /new-event를 세팅한다.
  • 클라이언트는 해당 응답의 301 코드를 받고, 동시에 Location 헤더가 존재하는지 검사한다. 헤더에 /new-event가 존재하므로 해당 위치로 리다이렉션되어 다시 /new-event에 대해 GET 응답을 전송한다.
  • 이제 해당 리소스가 존재하므로 서버는 해당 리소스를 응답 메시지에 넣은 뒤 정상 처리되었다는 것으로 200을 전송한다.

리다이렉션 과정

• 리다이렉션의 종류는 3가지로 나뉘어진다.
  • 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동한 경우
    • 예시로 /membrs로 지정된 URI가 /users로 변경된 경우가 있다.
  • 일시 리다이렉션 - 일시적인 변경일 때 사용한다.
    • 회원 가입 후 홈페이지로 돌아가거나, 주문 완료 후 주문 목록으로 돌아가거나 하는 경우를 일시적 리다이렉션이라고 말한다.
    • PRG 패턴 : Post/Redirect/Get
  • 특수 리다이렉션
    • 결과 대신 캐시를 사용하는 리다이렉션일 때 사용한다.

3XX 상태코드 상세

• 리다이렉션의 개념을 숙지하고 다시 상태코드로 돌아와 살펴보도록 하자.
• 영구적 리다이렉션은 301, 308 상태 코드로 2개가 존재한다.
  • 301 리다이렉션은 Moved Permanently라는 메시지로 리다이렉트 시에 요청 메서드가 GET으로 변환된다. 그리고 메시지 본문이 제거될 수 있다.
  • 308 리다이렉션은 Permanent Redirect로 301과 기능은 같으나 리다이렉트 시 요청 메서드는 이전에 요청한 메서드와 동일한 메서드를 사용하며 본문 역시 유지된다.
    • 이는 만약 POST로 요청을 보내었는데 308을 반환받을 시 리다이렉트 시에도 POST로 보낸다는 것이다.
    • 301은 POST로 요청을 보내었는데 리다이렉트 시 POST 요청이 GET으로 변환되어 전송된다.
• 일시적 리다이렉션은 302, 307, 303이 존재한다.
  • 302는 Found로 리다이렉트 시 요청 메서드가 GET으로 변경된다. 또한 본문이 제거될 수 있다.
  • 307은 Temporary Redirect로 302와 기능은 동일하나 요청 메서드와 본문을 유지한다는 점에서 302와 구분된다.
  • 303은 See Other로 302와 기능은 동일하나 본문이 제거되지 않는점이 차이점이다.

• 이런 리다이렉트의 특징을 이용하여 PRG 패턴이라는 것을 사용할 수 있다.

PRG(Post Redirect Get)

• 만약 우리가 어떠한 주문을 생성해서 서버로 POST를 통해 보내주었다고 생각해보자. 그 이후에 우리가 새로고침을 수행하면 어떤 일이 일어날까?
• 새로고침은 직전에 보낸 요청을 다시 서버로 보내는 동작을 수행한다. 즉 새로운 주문이 우리의 의도와는 전여 상관없이 생성된다. 이는 바람직하지 않은 결과이다.
• 이를 방지하기 위해 POST 주문 요청을 보낸 뒤에 주문 결과 화면을 GET 메서드로 리다이렉트한다.
• 이렇게 되면 직전에 수행한 요청이 GET 요청이므로 새로고침을 수행해도 잘못된 주문이 생성되지 않는다.

이외 코드

• 기타 코드로 304 Not Modified가 있다.
  • 해당 상태 코드는 캐시를 목적으로 사용된다.
  • 만약 클라이언트에서 캐시된 리소스를 사용하려고 할 때 서버와 차이가 있는지 확인을 수행하는 경우, 서버에서 해당 리소스를 확인하고, 변경된 점이 없다면 해당 상태 코드를 반환한다.
  • 이 경우 클라이언트는 캐시로 리다이렉트한다.
  • 이 경우 304 상태 코드는 응답에 메시지 바디를 포함하고 있으면 안된다. 왜냐하면 자신의 캐시를 사용해야 하기 때문이다.

 

 

정리

• 지금까지 200, 300번 상태 코드에 대해 알아보았다.
• 다음 포스트에서는 나머지 400, 500번 코드에 대해 알아본다.