HTTP 웹 기본 지식(6) - HTTP 상태코드

상태코드?

클라이언트가 보낸 요청의 응답 처리 상태

 

• 1xx (Informational): 요청이 수신되어 처리중

• 2xx (Successful): 요청 정상 처리

• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요

• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음

• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

 

231, 421 이라던지 상세한 코드들이 나타났을 때 당황하지 않고,

상위 상태 코드인 큰 단위만 보고 응답을 파악하고 대처하면 된다!

 

차례대로 자세히 살펴보자~!

-2xx(Successful)

-200: ok

요청 성공!

 

-201: created

location header 여부 확인 필요!

생성 성공!

 

-202: accepted

요청이 접수는 됐으나 처리가 완료되지 않음

배치 대기!

 

-204: no content

서버가 성공적 수행을 했지만 응답 페이로드 본문에 보낼 데이터가 없음

 

-3xx(Redirection)

: 요청 완료를 위한 유저의 추가 조치 필요

 

- 300: Multiple Choices (거의 안씀)

- 301: Moved Permanently

- 302: Found

- 303: See Other

- 304: Not Modified

- 307: Temporary Redirect

- 308: Permanent Redirect

 

먼저 리다이렉션이 뭐여?

-> 3xx 응답 결과 Location 에 헤더가 있으면 Location 위치로 자동 이동 (리다이렉트)

 

위 그림처럼 /event 라는 링크를 요청을 했는데, 사실 이 uri가 변경이 되었을 수 있다. 

이 때 다시 301로 Location: /new-event 로 바뀌었다고 응답을 준다.

그럼 클라이언트가 받고 아차차 하면서 /new-event로 다시 보낸다.

그럼 이제 다시 응답 200을 떨궈준다. 

 

이런 리다이렉션에는 크게 세 리다이렉션이 있다. 

1. 영구리다이렉션

 - URI가 영구적으로 바뀌어버린 경우
 - 301 Moved Permanently 

위 그림처럼 리다이렉트시 POST로 메세지 바디에 내용을 담아 보냈는데, 리다이렉트가 진행되며

요청 메서드가 GET으로 변하고 본문이 사라질 수 있다.

 

-308: Permanent Redirect

은 위 요청처럼 똑같이 보내더라도 아래 그림처럼 받고 보낼 때 POST로 내용을 유지하여 가지고 갈 수 있다. 

그치만 실무에서는 사실 URI 자체가 바뀌었다는 사실은 새로운 정보를 다시 받아야 할 경우가 대부분이기 때문에 

GET으로 받는 경우가 많다고 한다. 

 

 

2. 일시 리다이렉션

 - 리소스의 URI가 일시적으로 변경되기 때문에 검색 엔진 등에서 URL을 변경하면 안된다. 

 

- 302 Found

301과 매우 비슷하게 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있다. 

 

- 307 Temporary Redirect

302와 기능은 같지만 리다이렉트 요청 메서드와 본문을 유지한다. 요청 메서드를 변경하면 안된다.

 

- 303 See Other

302와 기능은 같고, 리다이렉트 시 요청 메서드가 GET으로 변경된다.

 

PRG: Post/Redirect/Get

일시적인 리다이렉션 - 예시

- POST 로 주문 후 웹 브라우저를 새로고침하거나,

- 새로고침을 하면 다시 요청하게 되는 상황

- 중복 주문이 되어버린다. 

-> 매매매매우곤란!@

 

아래 그림 처럼 PRG를 사용하지 않으면 위 상황이 발생되는 것이다 ..

상품을 넣고 주문을 넣었는데, 성공 주문이 데이터 저장이 됨! 200 완료

근데 거기서 다시 새로고침을 해버리면 같은 POST 요청을 보내버리게 되는 경우가 생겨버려

주문 데이터가 하나 더 생겨버릴 수 있다. 

 

그래서 PRG를 사용하는거다.

- 주문 후 새로고침으로 인한 중복 주문 방지

- 주문 후 주문결과를 get메서드로 리다이렉트를 해버린다.

- 새로고침을 해도 결과 화면을 get으로 조회할 수 있게 한다.

- 중복 주문 대신 결과 화면만 get으로 요청하게 되는것.

 

PRG를 사용하면 아래 그림처럼

 

POST로 주문 요청을 넣고 서버에서는 데이터를 저장 한 후 응답으로 200이 아닌

302 Found 로 Location을 새롭게 준다. 

그러면 새롭게 받은 URL로 GET 요청을 한다. 

그럼 주문 요청을 하는게 아니라 주문 데이터를 조회 하게 되고,

200으로 완료가 되는 것이다. 

 

현실적으로는 307,303을 권장하지만 이미 많이 302를 기본값으로 사용하고 있기 때문에

자동 리다이렉션시 GET으로 변해도 되면 302를 사용해도 큰 문제가 없다. 

 

3. 특수 리다이렉션

- 결과 대신에 캐시로 사용할 경우

 

304: Not Nodified

- 캐시를 목적으로 사용한다. 

- 클라이언트에게 리소스가 수정되지 않았음을 알려준다.

  따라서 클라이언트에게 캐시에 있는거 다시 쓰라고 하는거임.(야~~! 너 아직 그거 가지고 있잖냐~~! 그거 써~!)

- 304 응답은 응답에 메시지 바디를 포함할 수 없다.(로컬 캐시를 사용하라는 것이 명확하기 때문)

 

4xx (Client Error) 클라이언트 오류

- 클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없을 경우

- 오류의 원인이 클라이언트에 있음

- 클라이언트에 이미 잘못된 요청이 있기 때문에 똑같은 재시도해도 실패한다. 요청을 수정해서 보내야한다.

 

400 Bad Request

클라이언트가 잘못된 요청을 해서 서버가 요청을 처리 할 수 없음

- 요청 구문, 메세지 등 오류

- 클라이언트는 요청 내용을 다시 검토하고 보내야한다. 

- 요청 파라미터가 잘못되거나 API 스펙이 맞지 않을 때

 

401 Unauthorized

클라이언트가 해당 리소스에 대한 인증이 필요함

- 인증이 되지 않음

- 인증: 본인이 누구인지 확인 (로그인)

- 인가: 권한부여(ADMIN 특정 리소스에 접근할 수 있는 권한)

 

403 Forbidden

서버가 요청을 이해했지만 승인을 거부함

- 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우

- 어드민 권한 사용자가 아닌데 그 리소스에 접근하려고 할 경우

 

404 Not Found

요청 리소스를 찾을 수 없음

- 요청 리소스가 서버에 없음

- 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때 (오호~ 이건 몰랐네!)

 

5xx (ServerError)

서버오류

- 서버 문제로 오류 발생

- 서버에 문제가 있기 때문에 복구 시 재시도 하면 성공할 수 있음

 

500 Internal Server Error

서버 문제로 오류 발생, 애매하면 500 오류

 

503 Service Unavailable

서비스 이용불가

- 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음

- Retry-After 헤더 필드로 얼마뒤에 복구 되는지 보낼 수도 있음

 

** 개발자로서 비즈니스 로직 상 예외가 있을 경우는 예외처리를 잘 해두고, 정말 서버에 문제가 있을 때 500 에러가 나게 해야한다.