[Network] - HTTP 상태코드 정리

HTTP 상태코드

💡HTTP 상태코드란 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능입니다.
💡상태 코드는 개발자와 프로그램을 위한 것으로, 개발자가 상태 코드를 받아서 사용자에게 메세지로 변환해서 보여준다

HTTP 상태코드가 필요한 이유

💡웹 개발을 하다 보면 요청의 성공/실패 여부를 알아야 할 때가 있다. 
     ex) 회원 가입 요청을 보냈을 때 서버가 아무런 정보 없이 응답만 보내면 클라이언트 입장에서는 성공,실패 여부를 모름.

🎈상태 코드는 클라이언트가 보낸 요청의 처리 결과를 숫자로 알려주는 약속이다. 덕분에 클라이언트는 응답을 받자마자 성공인지, 실패인지, 어떤 종류의 오류인지 바로 파악할 수 있다.

상태 코드 구조

💡상태 코드는 세 자리 숫자로 이루어져 있고, 첫 번째 숫자에 따라 다섯 가지로 분류 된다.

상태 코드	분류	의미
1xx	Informational(정보성)	요청이 수신되어 처리중
2xx	Successful(성공)	요청 정상 처리
3xx	Redirection(방향 전환)	요청 완료를 위해 추가 행동 필요
4xx	Cleint Error(클라이언트 오류)	클라이언트 오류
5xx	Server Error(서버 오류)	서버 오류

---

1xx(Informational)

💡요청이 수신되어 처리 중임을 나타내며, 실무에서는 거의 사용하지 않는다.

---

2xx (Successful)

💡2xx는 클라이언트의 요청이 정상적으로 처리됐을 때 반환

200 (OK)

💡가장 기본적인 성공 응답

201 (Created)

💡새로운 리소스가 생성됐을 때 반환

✔️ 예시
POST /members 요청
→ 201 Created
→ Location: /members/100

🎈클라이언트의 요청에 따라 서버에서 생성돰
     ↳ POST는 서버가 자원을 생성하고 관리하며, 생성된 리소스는 응답의 Location 헤더 필드로 식별

 

202 (Accepted)

💡요청은 접수됐지만 처리가 아직 완료되지 않았을 때 반환(실무에서 잘 사용하지 않음)

✔️ 주로 배치 처리 같은 곳에서 사용
      ↳ 배치 처리 : 요청을 즉시 처리하지 않고, 모아뒀다가 특정 시간에 한 꺼번에 처리(1시간 뒤에 처리 등)

 

204 (No Content)

💡요청은 성공했지만 응답 바디에 보낼 데이터가 없을 때 반환

✔️웹 문서 편집기 저장 버튼 클릭
      ↳ 저장 버튼의 결과로 아무 내용이 없어도 되며, 같은 화면을 유지해야 함,

 

2xx 정리

코드	이름	의미	주요 사용 상황
200	OK	성공	GET 조회 성공
201	Created	생성 성공	POST 등록 성공
202	Accepeted	요청 접수, 처리 미완료	배치 처리
204	No Content	성공, 반환 데이터 없음	저장, 삭제 성공

---

3xx (Redirection)

💡3xx(Redirection)는 요청을 완료하기 위해 유저 에이전트(웹 브라우저)의 추가 조치가 필요하다는 의미
  
✔️ 너가 찾는 리소스가 다른 곳으로 이동했으니, 그쪽으로 가라고 안내하는 이정표 역할
       ↳ 3xx 응답을 보낼 때 Location 헤더에 새로운 주소를 담아서 보내면 브라우저가 자동으로 해당 주소로 이동

자동 리다이렉션 흐름

영구 리다이렉션(301, 308)

💡특정 리소스의 URI가 영구적으로 바뀌었을 때 사용
      ↳ ex) 서비스를 개편하면서 URL 구조가 바뀌는 경우(예전 주소: /members -> 새 주소 /users 로 영구 변경)

301 (Moved Permanently)

💡리다이렉트 후 요청 메서드가 GET으로 변경됨.(메시지 바디 내용이 사라질 수 있음)

308 (Permanent Redirect)

💡리다이렉트 후에도 요청 메서드 유지(POST로 요청 했으면 POST 유지, 메시지 바디도 유지)

---

일시 리다이렉션(302, 303, 307)

✔️URL이 일시적으로 바뀌는 경우를 의미하며, 실무에서 가장 많이 사용 됨
     ↳ 주문 완료 후 주문 내역 화면으로 이동

302 (Found)

💡일시적으로 다른 URI로 이동, 리다이렉트 후 대부분 GET으로 변경 됨

303 (See Other)

💡리다이렉트 후 GET으로 변경, PRG 패턴에서 주로 사용

307 (Temporary Redirect)

💡일시적으로 다른 URI로 이동, 리다이렉트 후에도 요청 메서드 유지(POST -> POST 유지, 요청 메서드 변경하면 안 됨)

---

PRG 패턴(Post/Redirect/Get)

💡PRG는 POST 요청 후 Redirect해서 GET 으로 바꾸는 패턴이다.

PRG가 필요한 이유

✔️쇼핑몰에서 주문 후, 새로 고침을 한다고 가정

- 주문 버튼 클릭
  마지막 요청 : POST /oders(주문 요청)

❗이 상태에서 새로 고침하면 중복 오류 발생(POST /oders 다시 전송)

새로고침은 마지막으로 보낸 요청을 다시 보내는 것

 

🎈위와 같은 문제 해결을 위해 POST 요청이 끝나면 바로 GET 요청으로 바꾸어 버리는 것이 핵심이다. 그러면 새로 고침해도 GET 요청만 반복하면 되니 중복 주문이 발생하지 않는다.

---

특수 리다이렉션(304 - Not Modified)

💡캐시 목적으로 사용하는 특수한 리다이렉션
     ↳ 로컬 캐시를 사용해야 하기 때문에 응답에 메시지 바디 포함 하면 안 됨

✔️동작흐름
1. 클라이언트 이미지 요청
    GET /images/logo.png

2. 서버(클라이언트에게 리소스가 수정 되지 않았음을 알림 -> 클라이언트는 로컬 PC에 저장된 캐시 재사용)
     ↳ 캐시로 리다이렉트 
   305 Not Modified

3. 클라이언트
   서버에서 새로 받지 않고 캐시 사용(속도 향상, 서버 부담 감소)

🎈다른 곳으로 이동하는게 아닌, 서버에서 새로 받을 필요 없이 저장해둔 캐시 사용해도 된다고 알려주는 것

 

---

4xx (Client Error)

💡4xx는 클라이언트가 잘못된 요청을 보냈을 때 발생하는 오류, 클라이언트의 요청 자체에 문제가 있는 경우
      ↳ 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 똑같은 재시도 실패 -> 오류의 원인이 클라이언트

400 (Bad Request)

💡요청 구문이나 데이터가 잘못됐을 때 반환

✔️ 예시 - API 스펙에 맞지 않는 요청
- 나이에 문자 작성 {"age":"스무살"}
- 필수 값(나이) 누락 {"username":"young"}  

400과 500의 차이

✔️ 400(클라이언트 오류)
     ↳ 요청 자체가 잘못, 똑같은 요청을 재시도 해도 계속 실패, 요청을 수정해야만 해결 가능

✔️ 500(서버 오류)
      ↳ 서버에 문제가 생긴 것으로, 서버 데이터베이스가 복구 되면 똑같은 요청을 재시도 해도 성공할 수 있음

🎈잘못된 요청은 반드시 400으로 처리 필요, 유효성 검사(Validation)를 통해 500 오류로 넘어가지 않도록 막아야 한다.

401 (Unatuhorized)

💡인증(Authentication)이 되지 않았을 때 반환, 쉽게 말하자면 로그인이 필요하다는 의미
     ↳로그인 되지 않은 상태에서 내 정보 조회 -> 만료된 토큰으로 요청

💡오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법 설명

✔️ 인증(Authentication) : 본인이 누구인지 확인(로그인)
✔️ 인가(Authorization) : 권한부여(ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)

403 (Forbidden)

💡인증은 됐지만 접근 권한이 없을 때 반환(로그인은 했지만 권한이 없음)
     ↳  ex) 일반 회원이 관리자 페이지 접근 

404 (Not Found)

💡요청한 리소스가 서버에 없을 때 반환
     ↳ 삭제된 게시글 조회, GET /members/999 -> 999번 회원이 없음 

✔️리소스가 실제로 존재하지만 클라이언트에게 숨기고 싶을때도 사용 가능
    ↳ 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때

---

5xx (Server Error)

💡5xx는 서버 내부에서 문제가 발생했을 때 반환.(클라이언트 요청은 정상)

500 (Internal Server Error)

💡서버 내부 문제로 오류가 발생했을 때 반환, 어떤 오류인지 애매할 때 500 사용

✔️ 서버 코드에서 예상치 못한 버그 발생(DB 쿼리 문제 및 DB 연결 문제)

503 (Service unavailable)

💡서버가 일시적으로 요청을 처리할 수 없을 때 반환.
     ↳ 일시적인 과부하 또는 예정된 작업으로 잠시 요청 처리 불가 -> 서비스 이용 불가

✔️Retry-After 헤더로 언제 복구 되는지 클라이언트에게 알려줄 수 있음 

🎈500 에러는 진짜 서버에 문제가 생겼을 때만 사용해야 하며, 비즈니스 로직상 발생하는 상황은 500 에러가 아니다