[HTTP] HTTP 상태코드

공부 내용을 정리하고 앞으로의 학습에 이해를 돕기 위해 작성합니다.

 

HTTP 상태코드

 

HTTP 상태코드란?

HTTP 상태 코드는 클라이언트가 보낸 요청에 대해 서버가 응답할 때, 그 요청이 어떻게 처리되었는지를 알려주는 숫자 코드이다. 이를 통해 클라이언트는 서버의 응답 상태를 쉽게 이해할 수 있다.

 

상태 코드 범주

• 1xx (Informational): 요청이 수신되어 처리 중임을 나타냄.
• 2xx (Successful): 요청이 정상적으로 처리되었음을 의미함.
• 3xx (Redirection): 요청을 완료하기 위해 추가 작업이 필요함을 의미함.
• 4xx (Client Error): 클라이언트의 요청에 오류가 있어 서버가 요청을 처리할 수 없음을 나타냄.
• 5xx (Server Error): 서버 내부 오류로 인해 요청을 정상적으로 처리할 수 없음을 나타냄.

모르는 상태 코드가 나타났을 때?

클라이언트는 인식할 수 없는 상태 코드를 서버로부터 받았을 경우, 해당 상태 코드를 상위 범주 코드로 해석하여 처리할 수 있다. 이를 통해 미래에 새로운 상태 코드가 추가되더라도 클라이언트는 별도의 변경 없이 해석이 가능하다.

예시

• 299 ??? → 2xx (Successful)
• 451 ??? → 4xx (Client Error)
• 599 ??? → 5xx (Server Error)

1xx (Informational)

1xx 코드는 요청이 수신되었고 처리가 진행 중이라는 것을 의미한다. 그러나 이 상태 코드는 거의 사용되지 않기 때문에 일반적으로 생략된다.

 

2xx - 성공

2xx 상태 코드는 클라이언트의 요청이 성공적으로 처리되었음을 나타낸다. 각각의 상태 코드는 요청에 대한 성공을 다양한 방식으로 표현한다.

 

200 OK

• 설명: 클라이언트의 요청이 성공적으로 처리되었음을 의미하며, 일반적으로 요청한 리소스가 응답 본문에 포함된다.
• 예시: 클라이언트가 서버에 특정 멤버의 정보를 요청한 경우, 서버는 그 멤버의 정보를 200 OK 상태 코드와 함께 반환한다.

201 Created

• 설명: 요청이 성공적으로 처리되어 새로운 리소스가 생성되었음을 의미한다. 생성된 리소스는 응답의 Location 헤더에 그 URI가 포함된다.
• 예시: 클라이언트가 새로운 멤버를 등록하면 서버는 201 Created 상태 코드와 함께 생성된 멤버의 URI를 응답한다.

202 Accepted

• 설명: 요청이 수신되었으나, 아직 처리가 완료되지 않았음을 나타낸다. 이 코드는 배치 처리와 같은 비동기 작업에서 주로 사용된다.
• 예시: 클라이언트가 서버에 대규모 작업을 요청했을 때, 그 작업이 즉시 처리되지 않더라도 202 Accepted 상태 코드가 반환될 수 있다.

204 No Content

• 설명: 서버가 요청을 성공적으로 처리했지만, 응답 본문에 보낼 데이터가 없음을 의미한다. 이는 클라이언트 측에서 화면이나 상태 변동 없이 그대로 유지되어야 할 때 유용하다.
• 예시: 사용자가 웹 문서 편집기에서 '저장' 버튼을 눌렀을 때, 서버는 데이터를 성공적으로 저장했으나 추가적인 응답 데이터가 없을 경우 204 No Content 상태 코드를 반환할 수 있다.

3xx - 리다이렉션

3xx 상태 코드는 요청을 완료하기 위해 추가적인 조치가 필요함을 나타낸다. 보통 사용자가 요청한 리소스가 이동되었을 때 서버는 3xx 상태 코드를 반환하고, 브라우저는 Location 헤더의 위치로 자동으로 이동하게 된다.

 

리다이렉션 이해- 자동 리다이렉트 흐름

리다이렉션은 웹 브라우저가 요청한 리소스가 다른 위치로 이동했을 때, 이를 처리하는 중요한 메커니즘이다. 서버가 클라이언트의 요청에 대해 리다이렉션 응답을 반환하면, 브라우저는 자동으로 새로운 위치로 요청을 다시 보낸다. 이를 통해 클라이언트는 별도의 조작 없이도 변경된 URL에서 리소스를 쉽게 가져올 수 있다.

• 클라이언트가 /event 경로로 GET 요청을 보낸다.
• 서버는 해당 리소스가 영구적으로 이동되었음을 나타내는 301 Moved Permanently 응답을 반환하고, 새로운 경로 /new-event를 Location 헤더에 포함한다.
• 클라이언트는 서버의 301 응답을 받아 자동으로 새로운 경로 /new-event로 GET 요청을 보낸다.
• 서버는 /new-event에 대한 요청을 처리하고 200 OK 응답과 함께 리소스를 반환한다.

리다이렉션의 종류

1. 영구 리다이렉션: 리소스의 URI가 영구적으로 이동됨을 나타냄.
   • 예시: /event -> /new-event
2. 일시 리다이렉션: 리소스의 URI가 일시적으로 변경됨을 나타냄. 주로 요청에 대해 즉시 응답하기 힘들 때 사용된다.
   • 예시: 주문 완료 후 주문 내역 화면으로 이동하는 경우.
3. 특수 리다이렉션: 캐시를 사용하여 리소스를 제공할 수 있을 때.

영구 리다이렉션 - 301

• 설명: 요청한 리소스가 영구적으로 새로운 URI로 이동되었음을 의미하며, 클라이언트는 이 URI를 앞으로 사용해야 한다.
• 특징: 리다이렉트 시 요청 메서드가 GET으로 변환되고, 본문이 제거될 수 있다.

영구 리다이렉션 - 308

• 설명: 301과 비슷하게 리소스가 영구적으로 이동되었음을 의미한다.
• 특징: 리다이렉트 시 요청 메서드와 본문이 유지된다.

302 Found

• 설명: 요청한 리소스가 일시적으로 다른 URI에서 제공됨을 의미한다. 그러나 리소스의 URI가 바뀐 것은 아니므로 클라이언트가 기존 URI를 계속 사용할 수 있다.
• 특징: 리다이렉트 시 요청 메서드가 GET으로 변환되고, 본문이 제거될 수 있다.

307 Temporary Redirect

• 설명: 302와 비슷하게 리소스가 일시적으로 다른 URI에서 제공됨을 의미한다.
• 특징: 리다이렉트 시 요청 메서드와 본문이 유지되며, 요청 메서드를 변경하면 안 된다.

303 See Other

• 설명: 클라이언트가 요청한 리소스가 다른 URI에서 제공됨을 나타낸다.
• 특징: 리다이렉트 시 요청 메서드가 GET으로 변경된다.

PRG: Post/Redirect/Get

PRG는 POST 요청 후 발생할 수 있는 문제를 방지하기 위해 사용되는 패턴이다. POST 요청 후 클라이언트가 새로고침을 하면 같은 요청이 다시 서버로 전송되어 중복 처리가 될 수 있기 때문에, 이 문제를 해결하기 위해 POST 요청 후 GET 요청으로 리다이렉트 하는 방식이다.

 

PRG 패턴의 흐름

1. 클라이언트는 POST 요청을 보냄.
2. 서버는 요청을 처리하고, 302 Found 상태 코드와 함께 리다이렉션 URI를 응답함.
3. 클라이언트는 자동으로 GET 요청을 보냄.
4. 서버는 GET 요청에 대한 응답으로 결과 페이지를 제공함.
5. 클라이언트가 새로고침을 하더라도, POST 요청이 아닌 GET 요청만 재전송되어 중복 문제가 발생하지 않음.

PRG 패턴 사용 전

1. POST 요청: 클라이언트는 /order URL로 POST 요청을 보낸다. 요청 본문에 itemId=mouse&count=1와 같은 데이터가 포함된다.
2. 데이터 저장: 서버는 요청을 받아 DB에 주문 데이터를 저장한다.
3. 응답: 서버는 주문이 성공했음을 알리는 200 OK 응답과 함께 주문 완료 페이지를 반환한다.
4. 새로고침: 사용자가 결과 화면에서 새로고침을 하면, 동일한 POST 요청이 다시 서버로 전송되며, 이로 인해 중복된 주문이 발생할 수 있다.
5. 중복 데이터 저장: 동일한 주문이 DB에 중복으로 저장된다.

PRG 패턴 사용 후

• POST 요청: 클라이언트는 /order URL로 POST 요청을 보낸다. 요청 본문에 itemId=mouse&count=1와 같은 데이터가 포함된다.
• 데이터 저장: 서버는 요청을 받아 DB에 주문 데이터를 저장한다.
• 302 Found 응답: 서버는 302 Found 응답을 반환하며, 클라이언트를 /order-result/19와 같은 결과 페이지로 리다이렉트 한다.
• 자동 리다이렉트: 클라이언트는 자동으로 GET 요청을 보내 /order-result/19 페이지를 조회한다.
• 주문 결과 페이지: 서버는 200 OK 응답과 함께 주문 결과 페이지를 반환한다.
• 새로고침: 사용자가 결과 페이지에서 새로고침을 하더라도 GET 요청만 다시 보내게 되므로, 주문 데이터가 중복 저장되지 않는다.

그래서 어떤 리다이렉션 코드를 써야 할까?

리다이렉션 시 주로 사용하는 상태 코드로 302, 307, 303이 있다. 각각의 차이와 사용 상황을 정리해 보면 다음과 같다.

• 302 Found: 요청이 다른 URI로 리다이렉트 될 때, 메서드가 GET으로 변경될 수 있다. 처음 의도는 메서드를 유지하는 것이었지만, 대부분의 브라우저가 GET으로 변경해 버리는 경우가 많다.
• 307 Temporary Redirect: 메서드를 유지해야 하는 경우 사용. 예를 들어, POST 요청이 리다이렉트될 때 메서드와 본문이 그대로 유지되어야 한다면 307을 사용해야 한다.
• 303 See Other: POST 요청 후, GET으로 리다이렉트 하고 싶을 때 사용한다. 이 상태 코드는 요청 메서드를 GET으로 변경하여 결과 페이지를 조회하게 한다.

리다이렉션 상태 코드 선택 가이드

1. 302 Found: 메서드가 GET으로 변해도 문제가 없으면 302를 사용한다. 대부분의 브라우저에서 기본적으로 302를 사용하므로 간편하게 적용 가능하다.
2. 307 Temporary Redirect: 메서드가 변하면 안 되는 경우에 307을 사용한다. POST 요청을 GET으로 바꾸면 안 되는 상황에서 유용하다.
3. 303 See Other: POST 요청 후, 결과 화면으로 GET 요청을 하도록 리다이렉트 할 때 사용한다. PRG 패턴에서 많이 사용되며, 중복 처리 문제를 방지하는 데 적합하다.

기타 리다이렉션 상태 코드

• 300 Multiple Choices: 거의 사용되지 않는다. 여러 개의 선택 가능한 리소스가 있을 때 사용되지만, 실제 사용 예시는 드물다.
• 304 Not Modified: 리소스가 수정되지 않았음을 나타내며, 클라이언트는 로컬 캐시를 사용하여 리소스를 불러온다. 조건부 GET 또는 HEAD 요청에 사용되며, 응답 본문을 포함하지 않는다.

결론

• 302 Found는 자동 리다이렉션 시 GET으로 변경되어도 괜찮다면 사용하는 데 큰 문제가 없다.
• 307 Temporary Redirect와 303 See Other는 보다 명확한 동작을 제공하므로 상황에 맞게 선택하면 좋다.

4xx - 클라이언트 오류

4xx 상태 코드는 클라이언트의 요청에 문제가 있어 서버가 요청을 처리할 수 없음을 나타낸다. 클라이언트의 요청이 잘못된 경우, 동일한 요청을 반복해도 실패하게 된다.

 

주요 4xx 상태 코드

• 400 Bad Request: 클라이언트가 잘못된 요청을 보냈을 때 발생한다. 요청 구문이나 메시지에 오류가 있을 경우 반환된다. 클라이언트는 요청 내용을 다시 확인하고 올바르게 수정해야 한다.
  예시: 잘못된 파라미터 전송 또는 API 스펙 오류.
• 401 Unauthorized: 해당 리소스에 접근하려면 인증이 필요함을 의미. 클라이언트는 인증되지 않았으며, 응답에 포함된 WWW-Authenticate 헤더를 통해 인증 방법이 설명된다.
  • 참고: 401은 인증(Authentication)이 필요함을 의미하며, 인가(Authorization)와는 다른 개념이다.
    예시: 로그인하지 않은 사용자가 보호된 리소스에 접근하려고 할 때.
• 403 Forbidden: 서버가 요청을 이해했지만, 권한이 없어 접근을 허용하지 않는 경우 발생. 인증은 되어 있지만, 권한이 부족한 경우에 주로 사용된다.
  예시: 일반 사용자가 어드민 전용 리소스에 접근하려고 할 때.
• 404 Not Found: 서버에서 요청한 리소스를 찾을 수 없을 때 발생. 리소스가 삭제되었거나 클라이언트가 잘못된 URL을 요청했을 때 반환된다.
  예시: 존재하지 않는 페이지를 요청하거나 권한이 부족한 리소스에 접근할 때.

5xx - 서버 오류

5xx 상태 코드는 서버 측의 문제로 인해 오류가 발생했음을 의미한다. 이 경우, 동일한 요청을 다시 시도하면 서버 복구 후에 성공할 수도 있다.

 

주요 5xx 상태 코드

• 500 Internal Server Error: 서버 내부에서 처리 중 문제가 발생했을 때 반환되는 일반적인 오류 코드. 명확한 원인을 알 수 없을 때 주로 사용된다.
  예시: 서버의 코드 오류나 설정 문제로 요청을 처리하지 못할 때.
• 503 Service Unavailable: 서버가 일시적인 과부하나 유지보수로 인해 요청을 처리할 수 없을 때 발생. 응답 헤더에 Retry-After 필드가 포함되어, 클라이언트가 언제 다시 요청할 수 있을지 알려줄 수 있다.
  예시: 서버가 과부하 상태 거나 유지보수 작업 중일 때.

결론

4xx 상태 코드는 클라이언트 측에서 문제를 수정해야 하는 오류이며, 5xx 상태 코드는 서버에서 문제가 발생했을 때 클라이언트가 재시도를 할 수 있는 오류이다. 각 상태 코드는 문제의 원인에 맞게 적절히 사용되어야 한다.