개요
- HTTP 상태코드란 클라이언트가 보낸 요청의 처리 상태를 서버의 응답에서 알려주는 값임.
- 적절한 상태코드를 서버에서 클라이언트로 return 해줌으로써 클라이언트가 그에 맞는 대처를 할 수 있기 위해 사용함.
- 100번대부터 500번대까지 존재함 → 100단위로 각각의 특성이 존재함.
100번대
- 거의 사용 X
200번대 (정상 처리)
200 OK
- ex) GET 요청 이후 정상 data return 시
201 Created
- ex) POST 요청 성공해서 새로운 리소스가 생성됨
- 생성된 리소스는 응답의 Location 헤더 필드를 알려줌
- 그러나 redirect를 시켜서 302 상태코드를 주기도 함
<주문완료 시나리오 상상(201/Location/2-step/POST 응답 body)>
주문완료 시나리오에서 주문완료 시 홈 또는 주문상세 페이지로 리다이렉트함.
이 때 주문상세 페이지로 가기 위해서는 주문 ID를 알아야 함. 주문 ID는 DB의 auto increment로 결정됨. 따라서 이를 또 다시 GET 요청으로 해야 함. 결국 투스텝으로 이루어지는 경우가 많음. (방금 등록된 것이 몇 번인지 Location 헤더 필드가 알려줌) 결국 이런 상황에서는 POST 요청 시 body가 있고, 응답에는 body가 없는데 body에 text를 담아서 주는 경우가 있음.상세 설명
- 주문 완료(POST) 이후 화면을 홈/주문상세로 보내는 흐름에서는 “방금 생성된 주문의 ID”가 필요해져서, 서버가 생성된 리소스의 위치를 알려주고 클라이언트가 다시 조회하는 2-step 패턴이 자주 발생함. 이때 일부 구현에서는 원래 비어도 되는 POST 응답 body에 주문 ID 같은 텍스트를 담아 한 번에 처리하기도 함.
주문완료 리다이렉트 기본 흐름
- 클라이언트가 주문 완료를 위해
POST /orders같은 요청을 보냄.- 주문이 DB에 저장되면서 주문 ID는 DB의 auto increment(또는 유사한 생성 전략)에 의해 “저장 시점”에 결정됨.
- 주문 완료 후 화면 이동은 보통 두 가지 중 하나임.
- 홈으로 리다이렉트
- 주문상세 페이지로 리다이렉트(예:
/orders/{orderId})주문상세로 가면 2-step이 되는 이유
- 주문상세 페이지로 이동하려면 URL에 들어갈
orderId를 알아야 함.- 그런데
orderId는 DB에 insert가 끝나야 확정되므로, 클라이언트가 POST를 보내기 전에는 정확한 값을 모름.- 그래서 실무에서 흔히 다음처럼 두 번 통신함.
POST /orders(주문 생성)- 생성된 주문 ID를 알게 된 뒤
GET /orders/{orderId}(주문상세 조회)서버가 “방금 등록된 ID”를 알려주는 방법
- 서버는 “방금 생성된 주문이 몇 번인지”를 클라이언트가 알 수 있게 응답에 힌트를 줌.
- 대표적으로 응답 헤더의
Location필드에 새로 생성된 리소스 주소를 넣음(예:Location: /orders/123).- 그러면 클라이언트는
Location을 보고 주문상세로 이동하거나, 필요 시GET으로 상세 데이터를 다시 가져올 수 있음.POST 응답 body가 비어 있는데도 넣는 경우
- 전형적인 형태는 “POST 요청은 body가 있고, 응답은 body가 없거나 최소화”되는 경우가 많음.
- 하지만 위처럼 2-step을 줄이기 위해, 일부 구현은 POST 응답 body에
orderId(또는 주문상세 URL, 간단한 텍스트/JSON)를 담아 내려주기도 함.- 결과적으로 클라이언트는 “응답 body에서 ID를 바로 얻어” 주문상세로 리다이렉트하거나, 추가 GET을 줄이는 방향으로 설계할 수 있음.
보충) 이 케이스는 “POST 성공 후 GET으로 상세 조회/화면 이동”이 자연스럽게 이어지는 대표 패턴임. 동시에 “POST 재시도 위험(멱등성)”과도 연결되므로, 결제/주문 쪽은 재요청 방지 설계가 특히 중요함.
300번대 (리다이렉션)
일반적으로 현재 페이지에서 다른 페이지로 리다이렉팅 되어야 함을 의미함.
301 (영구 리다이렉션)
- 영구 리다이렉션임.
- 아예 서버를 이전한 경우, 이전된 서버만 응답하는 것뿐만 아니라 상태코드 301, 308번을 주면서 리다이렉션을 하게 되는 경우 존재함. (FE에서 301이면 이전된 서버로 이동하는 코드를 작성하면 됨)
- 308이 더 최신 상태코드임.
- 예를 들어 google.com에서 google.net으로 변경됐을 경우 영구히 redirect임.
302 Found (일시적인 리다이렉션, 가장 많이 사용)
- 일시적인 리다이렉션임(가장 많이 사용).
- POST 요청 이후에 어딘가로 튕겨줘야 하는데 201로 가기도 하지만 302로 주는 경우가 더 많음.
- 307이 더 최신 상태코드임.
리다이렉션 활용 방법
- POST로 요청 이후 새로고침으로 인한 POST 요청 방지
- POST 요청 이후 302 + Location으로 결과 return
304 Not Modified (캐시)
- GET 요청 시 사용자가 가지고 있는 리소스가 캐시된 리소스임을 명시하기 위해 사용함.
- 클라이언트에게 리소스가 수정되지 않았음을 알려줌.
- 이미 사용자가 해당 리소스를 가지고 있으므로, 304 응답은 응답에 메시지 바디를 포함할 필요 없음.
<304 Not Modified (캐시) 시나리오 예시>
초기 로딩 때abc.html,abc.css,abc.js를 한 번 모두 내려받아 캐시에 저장해 둠. 이후 사용자가 새로고침을 하면, 브라우저(클라이언트)는 각 리소스가 “바뀌었는지”를 다시 요청해서 확인하는데, 이때 파일 자체를 다시 보내달라고 하는 게 아니라 파일의 생성/수정 시간 같은 기준(예: Last-Modified)으로 변경 여부만 확인함.새로고침 시 동작(변경 여부 확인)
서버는 각 리소스별로 변경 여부를 판단한 뒤, 리소스마다 응답 상태코드를 다르게 줄 수 있음.
- 변경 없음인 리소스 →
304 Not Modified
- 예:
abc.html = 304,abc.js = 304- 변경됨인 리소스 →
200 OK(최신 파일 내용을 내려줌)
- 예:
abc.css = 200
즉, 예시 상황에서는 “abc.html은 304야, abc.css는 200이야, abc.js는 304야”처럼 리소스별로 결과가 갈림.응답 바디(body)에 무엇이 담기나**
304인 리소스는 본문(body)을 보내지 않음(이미 클라이언트 캐시에 있는 것을 그대로 쓰라는 의미).200인 리소스만 본문(body)에 실제 파일 내용이 담겨 전송됨.- 그래서 위 예시에서는 응답할 때 body에는
abc.css(질문에 적힌 표현 그대로라면 “abd.css만”) 해당 파일 내용만 담아서 보내면 됨.왜 빨라지나
바뀌지 않은
abc.html,abc.js는 다시 다운로드하지 않고 캐시를 재사용하고, 바뀐abc.css만 내려받으므로 전송량과 처리 시간이 줄어 전체 로딩이 훨씬 빨라짐.
400번대 (클라이언트 오류)
클라이언트 오류임. 잘못된 문법 등으로 서버가 요청을 수행할 수 없음.
400 Bad Request
- 잘못된 요청과 구문임.
- ex)
http://localhost:8081/authors/findById?id→ 뒤에 숫자가 없어서 이런 문법 자체가 없음 - ex) 계산기에서 0으로 나눠버림 → 웹이라면 400을 응답코드로 보냈을 것
401 Unauthorized
- 서버로의 접속이 인증되지 않았을 때임.
- 즉, 로그인이 되지 않았을 때임.
403 Forbidden
- 인증 자격은 있지만 접근권한이 없을 때임.
404 Not Found
- 요청 리소스가 서버에 없을 때임.
- ex)
http://localhost:8081/authors/detail/1- 조회하고자 하는 사용자가 없을 때 404 return
500번대 (서버 오류)
- 서버 오류임. 서버가 정상 요청을 처리하지 못함.
주요 상태코드
- 500 Internal Server Error
- 별도의 지정된 상태 코드가 없을 때 대부분의 서버에서 예외 발생 시 return함.
- 503 Service Unavailable
- 서버가 일시적인 과부하 또는 예정된 작업으로 인한 일시적 오류를 의미함.
- 이미지 출처: 명진&클로드AI
