🌎 상태 코드
- 1xx: 요청이 수신되어 처리중
- 2xx: 요청 정상 처리
- 3xx: 요청 완료하려면 추가 행동 필요
- 4xx: 클라이언트 오류, 클라이언트가 다시 수정해야함
- 5xx: 서버 오류
🌎 1xx
- 거의 사용하지 않음
🌎 2xx(성공)
- 200 ok: 요청 성공
- 201 created: 요청 성공해서 새로운 리소스 생성
- 202 accepted: 요청이 접수되었으나 처리 안됨
- 204 no content: 서버가 요청을 성공적으로 수행했으나, 응답 페이로드 본문에 보낼 데이터가 없음 ex) save버튼을 누르면 아무결과 없이 저장만 됨
🌎 3xx(리다이렉션)
리다이렉션: 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동
event url로 접속을했지만 서버가 "이거 이제 안써 new-event로 들어가봐"라고 응답을 준다. 그러면 클라인트가 자동으로 new-event로 url을 설정하여 재접속한다
-
301 moved permanetly: 리다이렉트 요청 메서드가 GET으로 변하고 본문이 제거 될 수 있음.
-
308 permanent redirect: 301과 같은 기능이지만 POST로 보내면 POST를 유지한다.
-
302 found: 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음.
-
307 temporary redirect: 302와 기능은 같고 리다이렉트시 요청 메서드와 본문을 유지해야 함
-
303 see other: 302와 기능은 같고 무조건 리다이렉트시 요청 메서드가 GET으로 변경
-
304 not modified: 캐시를 목적으로 사용하고 만약 클라이언트가 서버에 이미지 다운에 대한 요청을한다면 다운이 아닌 어떤지 로컬PC에 저장된 캐시를 사용하는게 어떤지 캐시로 리다이렉트한다. 304 응답은 로컬캐시를 사용해야해서 메시지 바디를 포함하면 안된다.
🌎 PRG(POST REDIRECT GET)
post로 주문하고 웹브라우저를 새로고침하면은 다시 주문을 할 수 있다. 사실상 재주문의 가능성은 백엔드에서 방지를 해야하지만 더 안전하게하기위해 리다이렉션을 실행한다. post로 주문하면 get 메서드로 리다이렉트를 해서 새로고침을 해도 get을 통해 주문조회만 가능케한다.
- 307,303을 권장하지만 현실적으로 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용
- 자동 리다이렉션시에 GET으로 변해도되면 302를 사용해도 큰문제 없음.
🌎 4xx
- 클라이언트가 파라미터를 잘못 작성하는 등 잘못된 요청을 계속 보내고있어서 재시도를 해도 실패한다
- 400 bad request: 요청 파라미터가 잘못되거나 API 스펙이 안맞을 경우
- 401 unauthorized: 인증(로그인)과 인가(권한부여)가 필요함.
- 403 forbidden: 인증자격은있지만 접근권한이 불충분
- 404 not found: 요청 리소스가 서버에 없음.
🌎 5xx
- 500 internal server error: 서버 내부 문제로 오류 발생하고 애매하면 500 오류
- 503 service unavailable: 서버가 일시적인 과부화 또는 예정된 작업으로 잠시 요청을 처리 할 수 없음.
