Status Code(상태 코드)
상태 코드는 클라이언트가 보낸 요청의 처리 상태를 나타내며, HTTP 응답 메시지에 포함된다.
상태 코드는 100번대에서 500번대까지 존재하며, 첫 자리 숫자가 상태의 주요 범주를 나타낸다.
예: 성공(200번대), 리다이렉션(300번대), 클라이언트 에러(400번대), 서버 에러(500번대).
모르는 상태 코드 처리
상태 코드의 의미를 완전히 알지 못하더라도, 첫 자리 숫자로 요청 처리 상태를 유추할 수 있다.
예를 들어, 299 상태 코드를 응답 메시지에서 본다면 정확한 이슈는 몰라도 200번대이므로 요청이 성공했다는 것을 알 수 있다.
HTTP 상태 코드
1xx (Informational)
거의 사용하지 않으므로 생략.
2xx (Successful)
200 OK
요청이 성공적으로 처리되었으며, 클라이언트가 원하는 결과를 받았음을 의미한다.
201 Created
요청이 성공적으로 처리되었으며, 새로운 리소스가 생성되었음을 나타낸다.
생성된 리소스의 URI는 응답 메시지 헤더의 Location 필드에 포함된다.
202 Accepted
요청이 성공적으로 접수되었으나, 처리 완료까지 시간이 소요되는 경우 사용된다.
예: 배치 처리와 같이 처리가 지연되는 작업.
204 No Content
요청이 성공적으로 처리되었으나, 응답 본문에 보낼 데이터가 없는 경우 사용된다.
예: 문서 편집기에서 변경사항 없이 저장 버튼을 누르는 경우.
3xx (Redirection)
300번대는 클라이언트가 요청을 완료하기 위해 추가 조치가 필요함을 나타낸다.
웹 브라우저는 Location 헤더에 지정된 URI로 자동으로 리다이렉트한다.
리다이렉션의 종류
- 영구 리다이렉션: 리소스가 영구적으로 새로운 URI로 이동.
- 일시적 리다이렉션: 리소스가 임시적으로 다른 URI로 이동.
- 특수 리다이렉션: 특정 동작을 수행하는 리다이렉션.
영구 리다이렉션
301 Moved Permanently
리소스가 영구적으로 이동되었음을 나타낸다.
리다이렉트 시 요청 메서드가 GET으로 변경되고 본문이 제거될 수 있다.
308 Permanent Redirect
301과 동일하지만, 요청 메서드와 본문을 유지한다.
일반적으로 POST 요청의 본문을 유지한 채로 리다이렉트하는 것은 권장되지 않는다.
일시적 리다이렉션
302 Found
리소스가 임시적으로 이동되었음을 나타낸다.
리다이렉트 시 요청 메서드가 GET으로 변경되고 본문이 제거될 수 있다.
307 Temporary Redirect
302와 동일하지만, 요청 메서드와 본문을 유지한다.
303 See Other
302와 비슷하며, 리다이렉트 시 요청 메서드가 항상 GET으로 변경된다.
300번대 이해하기
영구 리다이렉션 vs. 일시적 리다이렉션
- 영구 리다이렉션은 URI가 영구적으로 변경되었음을 의미하며, 검색 엔진 등이 새로운 URI를 기억하고 인덱싱할 수 있도록 한다.
- 일시적 리다이렉션은 다시 이전 URI로 돌아갈 가능성이 충분히 있을 때 사용된다.
302를 사용하는 상황
리다이렉션 이전 URI로 다시 접근할 가능성이 있는 경우 302를 사용하는 것이 적절하다.
예:
- 주문 완료 후 주문 상세 페이지는 일시적으로 존재하며, 이후 다른 페이지로 돌아가거나 새로 요청할 가능성이 있다.
이러한 경우 302 Found가 적합하다.
301을 사용하는 상황
영구 리다이렉션은 과거 URI에서 새로운 URI로 이동해야 하며, 과거 URI로 다시 돌아갈 일이 없을 때 사용한다.
예:
- 웹사이트 구조 변경: 과거 URI가 더 이상 유효하지 않고, 새 URI로 완전히 대체된 경우.
- 서비스 이전: 도메인이 변경되거나 기존 리소스가 새 위치로 이동된 경우.
결론
영구 리다이렉션은 301로 처리하며, 과거 URI가 완전히 대체된 경우에 적합하다.
일시적 리다이렉션은 302로 처리하며, 다시 이전 URI로 돌아갈 가능성이 있는 상황에서 사용한다.
실제 웹 애플리케이션에서 302의 상황이 301보다 더 빈번하게 발생한다는 것을 예상할 수 있다.
303은 뭔데
303 See Other는 POST 요청의 리다이렉션을 더 편리하게 처리하기 위해 도입된 상태 코드이다. 과거에는 리다이렉션 시 302만 사용되었지만, POST를 리다이렉션하는 경우 요청 메시지 바디를 유지하는 것이 불편했고, 대부분의 경우 GET으로 전환하여 리다이렉션을 처리했다. 이를 표준화한 것이 303이며, 리다이렉션 시 항상 GET 메서드로 전환된다. 하지만 302 GET 리다이렉션이 이미 널리 사용되고 표준처럼 굳어져 있어, 현재도 많은 환경에서 302를 계속 사용하는 경우가 많다.
PRG (Post/Redirect/Get)
PRG(Post/Redirect/Get)는 POST 요청 후 바로 200 응답을 반환하지 않고, 리다이렉트를 통해 GET 요청으로 전환하는 방식이다.
이 방식은 POST 요청의 중복 처리를 방지하기 위한 설계 패턴이다.
PRG 동작 흐름
- POST /order
클라이언트가 데이터를 서버로 전송. - 302 Found Location: /order-result/19
서버가 POST 요청 처리 후 리다이렉트 응답. - GET /order-result/19
클라이언트가 리다이렉션된 URI로 GET 요청. - 200 OK
GET 요청 성공, 결과를 반환.
PRG를 사용하지 않을 경우
- POST /order
클라이언트가 데이터를 전송. - 200 OK
서버가 바로 성공 응답을 반환.
이 경우 클라이언트는 /order 위치에 머물며, 새로고침(F5)을 시도할 경우 POST 요청이 다시 전송된다.
이는 중복 처리를 유발하며, 백엔드에서 이를 방지하기 위해 400번대 에러를 반환하거나 추가 로직이 필요할 수 있다.
PRG 방식의 장점
PRG 방식을 사용하면 POST 요청 후 리다이렉트를 통해 중복 요청 문제를 방지할 수 있다.
사용자가 새로고침을 시도해도 GET 요청만 반복되므로, 백엔드에서 불필요한 에러 로그나 중복 처리를 피할 수 있다.
따라서 PRG 방식은 사용자 경험(UX)과 서버 안정성을 동시에 향상시키는 설계 패턴이다.
304 Not Modified
304 Not Modified는 주로 캐시를 목적으로 사용되며, 클라이언트에게 리소스가 수정되지 않았음을 알리는 상태 코드이다.
GET 요청에서 자주 사용되며, 클라이언트가 반복적으로 GET 요청을 보낼 때, 이전에 받은 응답이 캐시되어 있는 경우 서버가 새로운 데이터를 보내지 않고, 캐시된 데이터를 사용하도록 지시할 때 반환된다.
304 응답은 효율성을 위한 상태 코드로, 서버는 메시지 본문을 포함하지 않고, 클라이언트에게 캐시 데이터를 활용하라고 알린다.
따라서 304 응답에는 메시지 바디가 포함되지 않아야 한다.
4xx (Client Error)
클라이언트의 잘못된 요청으로 인해 서버가 요청을 수행할 수 없을 때 발생한다.
클라이언트가 잘못된 요청 데이터를 보낸 경우, 동일한 요청을 여러 번 반복하더라도 실패한다.
400 Bad Request
요청 구문에 오류가 있거나 메시지 형식이 잘못된 경우 발생한다.
클라이언트는 API 스펙이나 요청 파라미터를 재검토한 후 올바르게 수정하여 다시 요청해야 한다.
401 Unauthorized
클라이언트가 해당 리소스에 대한 인증(로그인)이 필요한 경우 발생한다.
이 응답에는 WWW-Authenticate 헤더가 포함되며, 지원되는 인증 방법에 대한 정보가 제공된다.
- Authentication(인증): 로그인이 되었는가?
- Authorization(인가): 인증 후 특정 리소스 접근 권한이 있는가?
403 Forbidden
서버가 요청을 이해했으나, 승인을 거부하는 경우 발생한다.
주로 인증은 되었으나 권한이 불충분한 경우 발생한다.
404 Not Found
요청한 리소스를 서버에서 찾을 수 없는 경우 발생한다.
또한, 권한 부족으로 리소스를 숨기고자 할 때도 사용할 수 있어 403과 중복 사용이 가능하다.
5xx (Server Error)
서버 자체의 문제로 인해 요청을 처리할 수 없을 때 발생한다.
이 경우 재시도하면 서버 복구 등으로 요청이 성공할 가능성이 있다.
500 Internal Server Error
가장 일반적으로 사용되는 서버 오류 코드로, 서버 내부 문제를 포괄적으로 나타낸다.
구체적인 원인을 정의하기 어려울 때 사용된다.
503 Service Unavailable
서버가 일시적인 과부하 또는 예정된 유지보수로 인해 요청을 처리할 수 없음을 나타낸다.
Retry-After 헤더를 포함해 복구 예상 시간을 알릴 수 있다.
