HTTP 상태 코드란?
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능을 말합니다. 이 상태 코드는 크게 아래의 5가지 범주로 나눌 수 있습니다.
• 1xx (Informational): 요청이 수신되어 처리중
• 2xx (Successful): 요청 정상 처리
• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
이를 통해 만약 모르는 상태 코드가 나타날 경우에는 상위 범주의 상태 코드로 해석하여 처리할 수 있습니다. 예를 들어, 299라는 상태 코드가 나타나면 이는 2xx(Successful) 범주에 속하므로, 클라이언트는 요청이 성공적으로 처리되었다고 판단합니다. 마찬가지로, 451이라는 상태 코드는 4xx(Client Error) 범주에 속하므로, 클라이언트는 클라이언트 오류로 해석하게 됩니다.
그럼 위의 5가지 상태 코드를 하나씩 살펴보겠습니다.
1xx (Informational)
요청이 수신되어 처리중이라는 상태입니다. 거의 사용하지 않습니다.
2xx(Successful)
클라이언트의 요청을 성공적으로 처리되었다는 것을 의미합니다.
200 OK, 201 Created, 202 Accepted, 204 No Content가 있습니다.
(1) 200 OK
가장 일반적으로 사용되는 상태 코드로, 클라이언트의 요청이 서버에 의해 정상적으로 처리되었음을 의미합니다.
(2) 201 Created
요청으로 새 리소스가 생성되었음을 나타냅니다. 주로 POST 요청이 성공하고 새로운 리소스가 생성되었을 때 반환됩니다.
그림처럼, 새로운 사용자 계정이 생성되었을 때 사용될 수 있습니다.
(3) 202 Accepted
요청이 접수되었으나 처리가 완료되지 않았음을 나타냅니다. 주로 비동기 작업이나 배치 처리와 같은 상황에서 사용됩니다. 클라이언트의 요청이 접수되었지만 서버가 아직 처리를 완료하지 않았음을 의미합니다.
(4) 204 No Content
서버가 요청을 성공적으로 수행했지만, 응답에 본문 데이터가 없음을 나타냅니다.
주로 클라이언트가 서버에 데이터를 전송하고자 할 때 사용됩니다. 예를 들어, 웹 문서 편집기에서 '저장' 버튼을 누른 경우 서버는 성공적으로 요청을 처리했지만 콘텐츠를 반환할 필요가 없는 경우에 해당합니다. 클라이언트는 단순히 요청의 성공 여부만을 확인하면 되기 때문에 본문 데이터가 없어도 됩니다.
3xx - 리다이렉션
리다이렉션은 클라이언트의 요청을 완료하기 위해 추가적인 조치가 필요할 때 사용되는 HTTP 상태 코드입니다.
• 300 Multiple Choices • 301 Moved Permanently • 302 Found • 303 See Other • 304 Not Modified • 307 Temporary Redirect • 308 Permanent Redirect
(1) 리다이렉션이란?
우선 리다이렉션이란 웹 브라우저가 서버로부터 받은 3xx 응답에 Location 헤더가 있으면, 그 위치로 자동으로 이동하는 것을 의미합니다.
이를 통해 클라이언트는 다른 위치로 리다이렉션되고, 새로운 리소스를 요청하게 됩니다.
(2) 리다이렉션 종류
1. 영구 리다이렉션
특정 리소스의 URI가 영구적으로 이동되었음을 나타냅니다. 예를 들어, /members 경로가 /users로 영구적으로 이동되었다면, 이후에는 /users 경로를 사용해야 합니다.
2. 일시 리다이렉션
일시적인 변경을 의미합니다. 주문 완료 후 주문 내역 화면으로 이동하는 것과 같이, 일시적인 리다이렉션이 발생할 수 있습니다.
한 예로, PRG(Post/Redirect/Get) 패턴이 있습니다. PRG패턴이란 사용자가 POST 요청을 보내고, 서버에서 처리한 후에 리다이렉트하여 GET 요청을 받는 것을 의미합니다. 예를 들어, 주문 완료 후 주문 내역 화면으로 이동하는 경우에 사용됩니다.
3. 특수 리다이렉션
결과 대신 캐시를 사용하는 리다이렉션입니다. 이는 주로 캐시를 목적으로 사용됩니다.
영구 리다이렉션 301, 308
(1) 301 Moved Permanently
리소스의 URI가 영구적으로 이동되었음을 나타냅니다. 클라이언트는 이후에는 해당 리소스의 새로운 URI를 사용해야 합니다. 검색 엔진 등에게도 변경을 알리는데 사용됩니다. 301 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있습니다.
(2) 308 Permanent Redirect
301과 기능은 동일하지만, 리다이렉트시 요청 메서드와 본문을 유지합니다. 즉, 최초의 POST 요청을 받았을 때에도 리다이렉트 시 POST 요청을 유지합니다.
일시적인 리다이렉션 302, 307, 303
(1) 302 Found
리소스의 URI가 일시적으로 변경된 것을 나타냅니다. 클라이언트는 새로운 URI를 사용하지만, 이 변경은 일시적인 것이므로 검색 엔진 등에서는 변경을 기록하지 않아야 합니다.
(2) 307 Temporary Redirect
302와 기능은 동일하지만, 요청 메서드와 본문을 유지합니다. 따라서 요청 메서드를 변경하면 안됩니다.
(3) 303 See Other
: 302와 기능은 동일하지만, 요청 메서드가 GET으로 변경됩니다. 이는 PRG(Post/Redirect/Get) 패턴에서 주로 사용됩니다.
PRG: Post/Redirect/Get
RPG에 대해 더 자세히 알아보겠습니다. 만약 POST로 주문후에 웹 브라우저를 새로고침하면 새로고침은 다시 요청을 하는 것이기 때문에 중복 주문이 될 수 있습니다.
그래서 이런 중복 주문을 방지하기 위해서 POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트하게 됩니다. 그러면 새로고침해도 결과 화면을 GET으로 조회하기 때문에, 중복 주문 대신에 결과 화면만 GET으로 다시 요청하게 됩니다.
결론적으로, 307, 303을 권장하지만 현실적으로는 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용합니다. 따라서 자동 리다이렉션 시에 GET으로 변환되어도 큰 문제가 없다면 302를 사용해도 괜찮습니다. 하지만 명확한 동작을 위해서는 307이나 303을 사용하는 것이 좋습니다.
4xx - 클라이언트 오류
클라이언트가 잘못된 요청이나 데이터를 보내고 있어서 서버가 요청을 수행할 수 없을 때의 상태 코드입니다.
(1) 400 Bad Request
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없다는 의미입니다.
주로 요청의 구문이나 메시지 등에 오류가 있는 경우에 발생하며, 클라이언트는 요청 내용을 다시 검토하고 수정하여 보내야 합니다. 요청 파라미터가 잘못되었거나 API 스펙이 맞지 않는 경우에 이 상태 코드가 반환될 수 있습니다.
(2) 401 Unauthorized
클라이언트가 해당 리소스에 대한 인증이 필요함을 의미합니다. 클라이언트가 인증되지 않았으며, 인증이 필요한 리소스에 접근하려고 할 때 발생합니다. 이 상태 코드가 반환되면 응답에는 WWW-Authenticate 헤더가 포함되어 클라이언트에게 어떤 인증 방법을 사용해야 하는지 알려줍니다.
(3) 403 Forbidden
서버가 요청을 이해했지만 승인을 거부했음을 나타냅니다. 클라이언트가 인증 자격 증명을 가지고 있지만, 요청한 리소스에 대한 접근 권한이 없는 경우에 이 상태 코드가 반환됩니다. 예를 들어, 어드민 등급이 아닌 사용자가 특정 리소스에 접근하려고 할 때 발생할 수 있습니다.
(4) 404 Not Found
요청한 리소스를 찾을 수 없음을 나타냅니다. 요청한 리소스가 서버에 없거나 클라이언트가 권한이 부족한 리소스에 접근하려고 할 때 해당 리소스를 숨기고 싶을 때 발생할 수 있습니다.
5xx - 서버 오류
서버 오류는 클라이언트 요청을 처리하는 동안 서버 측에서 문제가 발생했음을 나타냅니다.
서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있습니다.(복구가 된다면)
(1) 500 Internal Server Error
서버 내부에서 오류가 발생하여 요청을 처리할 수 없음을 나타냅니다. 애매한 상황이면 500을 던지기 때문에 클라이언트에게 구체적인 오류 내용을 제공하지 않습니다.
(2) 503 Service Unavailable
서버가 일시적인 과부하나 예정된 작업으로 인해 잠시 요청을 처리할 수 없음을 의미합니다.
클라이언트는 Retry-After 헤더 필드를 통해 몇 초 후에 서비스가 다시 이용 가능해질 것인지 확인할 수 있습니다.
참고자료
[인프런 김영한 - 모든 개발자를 위한 HTTP 웹 기본 지식]
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard
'Backend > HTTP' 카테고리의 다른 글
[HTTP] HTTP 헤더 - 일반 헤더 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 7) (0) | 2023.04.25 |
---|---|
[HTTP] HTTP 메서드 활용 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 5) (0) | 2023.04.25 |
[HTTP] HTTP 메서드 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 4) (0) | 2023.04.21 |
[HTTP] HTTP 기본 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 3) (0) | 2023.04.20 |
[HTTP] URI와 웹 브라우저 요청 흐름 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 2) (0) | 2023.04.18 |