[CS] HTTP 상태 코드

상태코드

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

 

1XX (informational) : 요청이 수신되어 처리중

2XX (Successful) : 요청 정상 처리

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

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

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

 

 *만약 모르는 상태코드가 나오더라도 위와같이 큰 틀에서 이해하고 해결할 수 있다.

예) 299 / 451 / 599 에러 등

 

아래에서 상태코드에 대해 자세히 알아보자.

---

1XX (informational) : 요청이 수신되어 처리중

- 거의 사용하지 않음

 

---

2XX (Successful) : 요청 정상 처리

- 200 OK 

  => GET요청을 보내면 서버에서 정상적인 결과를 응답해준다

 

- 201 Created

  =>  요청을 한것을 가지고 서버에서 리소스를 생성완료(POST 등)

 

- 202 Accepted

  = > 요청이 접수되었으나 처리가 완료되지 않음.

 예 ) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리한다.

 잘 사용하지않음.

 

- 204 No Content

 => 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음.

 예) 웹 문서 편집기에서 save 버튼

 save 버튼의 결과로 아무 내용이 없어도 된다.

 save 버튼을 눌러도 같은 화면을 유지해야 한다.

 결과 내용이 없어도 204메시지 만으로 성공을 인식할 수 있다.

---

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

=> 웹 브라우저는 3XX 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동

 

예를 들어보면,

 

이벤트페이지를 다른 페이지로 바꾸고 싶다.

하지만, 이전에 사용자들이 북마크를 하던, 어느 방법으로 이전에 사용한 이벤트페이지만 알고 있다.

사용자는 GET /event로 서버에 요청을 한다.

서버에서는 301을 사용해서 Location:/new-event 로 새로운 페이지를 클라이언트에게 알려준다.

웹 브라우저는 받은 URL을 서버에 다시 요청한다.

정상적으로 서버는 200 으로 응답한다.

 

 

리다이렉션에는 3가지 종류가 있다.

 

1. 영구 리다이렉션 - 특정 리소스의 URI 가 영구적으로 이동

 => 위와 같은 상황

 원래의 URL을 사용하지않고, 검색 엔진 등에서도 변경을 인지한다. 

 예 ) /event -> /new-event

 301과 308 이 있다.

 둘의 기능은 같다

 

 

2. 일시 리다이렉션 - 일시적인 변경

 - 검색 엔진 등에서 URL을 변경하면 안된다.

 - 주문 완료 후 주문 내역 화면으로 이동

 - PRG : POST / Redirect / Get

 

- 302 Found ( 디폴트값으로 많이 사용한다 )

  리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거 될 수도 있음.

 

- 307 Temporary Redirect

 302와 가능은 같다. 

 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다.)

 

- 303 see Other

 302와 기능은 같다.

 리다이렉트시 요청 메서드가 GET 으로 변경

 

- 304 Not Modified

캐시를 목적으로사용한다

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

 

예시)

큰 이미지가 있는데 캐시가 만료되었는데 서버에게 다시 내려달라고 한다.

서버는 그냥 캐시에 있는걸 쓰라고 클라이언트에게 알려준다.

이미지 자체를 보내지 않아도 되기때문에 저장되어 있었던 큰 이미지를 바로 사용할 수 있다. (데이터절약)

따라서, 304응답은 메시지 바디를 포함하면 안된다 ( 로컬에 있는 캐시를 사용해야 하므로 )

 

 

 

PRG : POST / Redirect / Get

POST로 주문후에 웹 브라우저를 새로고침하면 어떻게 될까?

새로고침은 다시 요청과 같다.

그럼 주문이 중복으로 될 수 있다.

 

ㅡ

 

이러한 문제를 해결하기 위해 PRG 를 쓴다.

 

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

POST 로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트

새로고침해도 결과 화면을 GET으로 조회

중복 주문 대신에 결과 화면만 GET으로 다시 요청

 

URL 이 이미 POST -> GET 으로 리다이렉트가 되어서 

새로고침을 해도 GET으로 결과 화면만 조회된다.

 

 

---

 

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

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

- 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패한다.

 

400 Bad Request

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

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

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

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

 

401 Unauthorized

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

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

인가(Authorization) : 권한부여 (인증을 해야 인가가 있다)

 

403 Forbidden

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

주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우 ( 인증은 했지만, 권한이 없는 곳에 요청 )

 

404 Not Found

요청 리소스를 찾을 수 없음

요청 리소스가 서버에 없음

또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때 사용

---

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

- 서버 문제로 오류 발생

- 서버에 문제가 있기 때문에, 재시도 하면 성공할 수도 있음(복구가 되거나 등등..)

 

500 Internal Server Error - 99.99% 이것만 사용한다

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

 

503 Service Unavailable - 거의 안쓴다

서비스 이용 불가

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

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