[HTTP] HTTP 상태 코드

1. 상태코드?

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

- 당연하지만, 서버의 응답 메시지에 상태코드가 담기게 된다.

>> 404 not found

(일의자리까지 정확히 외울 필요는 없지만 404 처럼 익숙한 상태 코드들이 있으니,,알면 좋겠다!)

 

• 1xx (informational) : 요청이 수신되어 처리중 (거의 사용하지 않음.)
• 2xx (Successful) : 요청 정상 처리
• 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error) : 클라이언트 오류 (잘못된 문법..)
• 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함 

각각 "200번대", "300번대" 상위 상태코드로 해석하여 처리하면 된다.

 

2. 2xx - 성공 

100번대는 거의 사용하지 않는 상태코드이므로 패쓰..!

• 200 OK : 요청 성공 
• 201 Created : 요청 성공으로 새로운 리소스가 생성됨
  생성된 리소스에 대한 Location 헤더가 응답 메시지에 담기게 된다. 
• 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않음
  - 배치 처리 같은 곳에서 사용
• 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
  - 만약 클라이언트 요청이 save이면, 저장만 수행하면 될 뿐, 클라이언트에게 보낼 데이터가 딱히 없으므로 save 결과로 아무 내용이 없어도 된다. (단, save 버튼을 눌러도 같은 화면을 유지해야 한다.)
  
  

3. 3xx - 리다이렉션

리다이렉트라는 용어 자체는 콜백 배울 때 주구장창..배웠을..그 리다이렉트이다!

경로 재설정으로 이해하면 편한데, 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, 그 Location 경로로 자동 이동한다.

 

클라이언트가 /event 조회를 시도했다. 서버는 301이라는Location 헤더에 /new-event 경로를 담고 응답을 보내며,

클라이언트는 /new-event로 리다이렉트된다. 그럼? 서버는 그냥 그 경로로 보내고 오케이 코드를 보내면 끝이다.

 

3.1) 리다이렉션 종류

• 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동
  예를들어, /members라고 하는 URI를 들어가니, /users로 인도하는 것이다.
• 일시 리다이렉션 : 일시적인 변경
  주문 완료 후에 주문 내역 화면으로 이동하는 경우이다. 영구적으로 내역 화면으로 보내버리는 게 아니기 때문에..
  - PRG : Post/Redirect/Get
• 특수 리다이렉션 : 결과 대신 캐시를 사용

 

3.2) 영구 리다이렉션 : 301, 308

• 리소스의 URI가 영구적으로 이동한다.
• 원래의 URL을 사용하지 않고, 검색 엔진에서도 변경됨을 인지한다.

 

 

• 301 Moved Permanently : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.
• 308 Permanent Redirect : 301과 기능은 같지만, 리다이렉트시 요청 메서드와 본문이 유지된다.

 

3.3) 일시적인 리다이렉션 : 302, 307, 303

• 리소스의 URI가 일시적으로 변경된 것이다.
• 검색 엔진 등에서 URL을 변경하면 안된다.
• 302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.
• 307 Temporary Redirect : 302와 기능은 같지만, 리다이렉트시 요청 메서드와 본문이 유지된다.
• 303 See Other : 302와 기능은 같지만, 리다이렉트시 요청 메서드가 GET으로 변경된다.

PRG : Post/Redirect/Get

PRG는 일시적인 리다이렉션의 예시이다. 

POST로 주문한 후, 웹 브라우저를 새로고침하면?

-> 새로고침은 다시 요청한다는 뜻이다.

-> 중복 주문이 된다.

 

이러한 사태를 막으려면, 

POST로 주문 한 후에, 주문 결과 화면을 GET 메서드로 리다이렉트 시켜야 한다.

새로고침을 하더라도, 결과 화면을 GET으로 "조회"해야한다는 것이다.

그게 아니라 계속 POST로 요청 메서드가 유지되어버리면 우리는 새로고침할 때마다 주문하게 되는 것이다..ㅜㅜ

 

PRG

 

위 흐름을 보면,

 

- 처음에 클라이언트가 POST /order로 item을 주문했고

- 서버에서는 302 Found 답변과 함께 /order-result/19(19는 임의 주문 번호)인 주문 결과 화면으로
   GET 메서드와 함께 리다이렉트 시킨다.

- 클라이언트는 결과 화면에서 새로고침하더라도 계속 같은 결과 화면으로 이동

 

 

3.4) 기타 리다이렉션

• 300 Multiple Choices : 안 쓴다.
• 304 Not Modified : 캐시를 목적으로 사용한다. (다다음 게시글에서 캐시를 다룰 때 설명)
  
  

4. 4xx - 클라이언트 오류

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

오류 원인 자체가 클라이언트에게 있다.

4xx 오류는 아무리 재시도하더라도, 애초에 잘못된 요청을 요구하고 있는 것이기 때문에 계속 실패한다. 
5xx 오류는 서버에 장애가 생기거나, 지연되는 경우에 발생할 수 있어, 재시도했을 때 성공할 수도 있다.

 

• 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
  - 클라이언트는 요청 내용을 다시 검토하고 보내야 함
• 401 Unauthorized : 클라이언트가 해당 리소스에 대한 "인증"이 필요함
  - 인증과 인가으 개념에 대해 익히 알겠지만, 이 상태코드는 명확히 "인증"이 필요하다는 것을 의미한다.
  - 즉, 본인이 누구인지 확인하는 절차가 필요하다는 의미이다.
• 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함
  - 인증 자격은 있지만, 접근 권한을 불충분한 경우
• 404 Not Found : 요청 리소스를 찾을 수 없음
  - 요청 리소스가 서버에 없음
  - or 클라이언트가 권한이 부족한 리소스에 접근할 때, 해당 리소스를 숨기고 싶을 때

 

5. 5xx - 서버 오류

서버 문제로 오류가 발생한 경우이다.

개발자는 500번대 오류를 웬만해선 만들면 안된다.

 

예를 들어, 비즈니스 로직의 예외인 케이스가 요청으로 들어온 경우를 5xx 오류로 내보내면 안된다.

정말 서버가 터지거나, 해결하기 버거운 장애가 생겼을 때 발생하는 것이다.

 

• 500 Internal Server Error : 서버 문제로 오류 발생, 그냥 애매하면 500 오류로
• 503 Service Unavailable : 서버가 일시적인 과부화 또는 예정된 작업으로 잠시 요청 처리가 불가할 때
  - Retry-After 헤더 필드로 얼마 뒤에 복구되는지 안내할 수 있다.

 

 

[참고] : 인프런-김영한 <모든 개발자를 위한 HTTP 웹 기본 지식>