HTTP 상태코드

HTTP 상태코드 : 클라이언트가 서버로 보낸 요청의 처리 상태를 응답에서 알려주는 기능.

 

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

 

클라이언트가 인식할 수 없는 상태코드를 서버가 반환하는 경우

- 클라이언트는 상위 상태코드로 해석해서 처리(2xx대, 3xx대 등)

- 299와 같은 인식할 수 없는 상태코드가 반환되면 2xx(Successful)로 받아 요청을 정상 처리했다고 해석.

- 따라서 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경할 필요 없다.

---

주로 사용하는 상태코드

1xx (Informational)

 - 요청이 수신되어 처리 중이다.

 - 실무에서도 거의 사용하지 않는다.

---

2xx (Successful)

1. 200 ok

 - 요청이 정상적으로 잘 처리되었다.

 

2. 201 Created

 - 요청이 성공해서 새로운 리소스가 생성되었다.

 - post 요청이 정상적으로 처리되었다!

 - 생성된 리소스는 응답의 Location 헤더의 필드로 식별할 수 있다.

 

3.  202 Accepted

 - 요청이 접수되었으나 처리가 완료되지는 않았음.

 - 요청 접수 후 1시간 뒤에 요청을 처리하는 경우.

 - 잘 사용하지는 않음.

 

4. 204 No Content

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

 - ex) 웹 문서 편집기의 save 버튼. 특별한 응답받을 필요 없이 요청만 잘 수행하면 됨.

 

모든 상태코드들을 다 사용하는 것이 아니고 보통 프로젝트 내에서 어느 정도로 디테일하게 사용할 것인지 약속하고 사용하기로 한 코드들만 사용한다. 2xx대의 경우 200 ok만 사용하는 경우도 빈번하다.

---

3xx (Redirection)

 - 요청을 완료하기 위해 유저 에이전트(웹 브라우저)의 추가 조치 필요.

 

리다이렉트(Redirect)란?

 : 클라이언트의 요청에 대해 새로운 URL로 접속할 수 있도록 응답을 보내 재요청시키는 것.

 

https://www.inflearn.com/course/lecture?courseSlug=http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC&unitId=61372

 

리다이렉션의 종류

 

1. 영구 리다이렉션

- 특정 리소스의 URI가 영구적으로 이동된 경우.

- 원래의 URL을 사용하지 않고, 검색 엔진 등에서도 변경을 인지할 수 있음.

- ex) /event -> /new-event

301 Moved Permanently	리다이렉트시 요청 메소드가 GET으로 변하고, 본문이 제거될 수 있다. 대부분의 경우 제거됨.
308 Permanent Redirect	리다이렉트시 요청 메소드와 본문 유지시켜 줌.

- 실무에서는 308은 거의 사용하지 않는다. 301도 잘 사용하지 않음. 즉, 영구 리다이렉션 자체를 잘 사용하지 않는다. 

- URI가 영구적으로 이동되면 보통 내부적으로 전달되는 데이터 자체가 다 바뀌기 때문.

 

 

2. 일시 리다이렉션

- 일시적으로 잠깐 이동시킬 때 사용.

- ex) 주문 완료 후 주문 내역 화면으로 자동으로 이동시키는 경우.

302 Found	리다이렉스시, 요청 메소드가 GET으로 변하고, 본문이 제거될 수 있다.(대부분 제거됨.)
307 Temporary Redirect	리다이렉트시, 요청 메소드와 본문  유지(요청 메소드를 변경하면 안됨.)
303 See Other	리다이렉트시, 요청 메소드가 GET으로 변경.

- 실무에서는 아직 302를 사용하고 있음.

 

※ PRG 패턴 : Post/Redirect/Get 

Post로 요청한 후 웹브라우저를 새로고침 하면 해당 Post 요청이 다시 들어갈 수 있음.

-> Post로 요청 후 결과 화면을 get 메소드로 리다이렉트 시킴.

 

 

3. 특수(기타) 리다이렉션

 - 요청의 결과 대신 캐시를 사용하는 경우.

 - 304 Not Modified - 캐시를 목적으로 사용. 클라이언트가 특정 리소스에 대한 정보를 서버에 요청하는데 서버에서는 해당 리소스가 클라이언트의 캐시에 저장되어 있고, 수정된 사항이 없으니 캐시에 저장된 리소스를 다시 사용해도 된다는 의미로 캐시로 리다이렉트 시켜줌. 로컬 캐시를 사용해야 하므로 응답에 메시지 바디를 포함하면 안 됨.

---

4xx (Client Error)

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

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

 - 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 요청은 계속 실패하는 반면, 5xx는 서버의 오류이기 때문에 똑같은 재요청이 성공할 수 있음.

400 Bad Request	- 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음.  - 클라이언트는 요청 내용을 다시 검토하여 보내야 함
401 Unauthorized	- 클라이언트가 해당 리소스에 대한 인증이 필요함.  - 401 오류 발생시, 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명해줘야 함.
403 Forbidden	- 서버가 요청을 이해했지만 승인을 거부함.  - 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우.
404 Not Found	- 요청 리소스를 찾을 수 없음.  - 또는 클라이언트가 권한이 부족한 리소스에 접근할 때, 해당 리소스를 숨기고 싶을 때 사용.     (권한이 부족한 클라이언트에게는 이건 원래 없는 리소스다! 라고 알려주고 싶을 때)

---

5xx (Server Error)

 - 서버 문제로 오류 발생.

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

500 Internal Server Error	서버 내부 문제로 오류 발생. 애매하면 500 오류 내면됨.
503 Service Unavailable	서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없는 경우.

 

웬만하면 500대 에러를 만들어내면 안 됨. 정말 서버에 문제가 터졌을 때만 500대 에러를 내야 함.