[1] HTTP 상태코드 소개
상태코드: 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
📌 상태코드 요약
1xx: (Informational) 요청이 수신되어 처리 중
2xx: (Successful) 요청 정상 처리
3xx: (Redirection) 요청을 완료하려면 추가 행동 필요
4xx: (Client Error) 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5xx: 서버 오류, 서버가 정상 요청을 처리하지 못함 → 새로고침하면 될 수도
모르는 상태코드가 나타났을 땐 (클라이언트가 인식 불가능한 상태코드를 서버가 반환한다면) 299라면 2xx의 successful로 해석하듯 클라이언트는 상위 상태코드로 해석해 처리한다.
1xx (Informational)
: 요청 수신돼 처리 중. 거의 사용하지 않음
[2] 2xx - 성공
(Successful)
: 클라이언트의 요청을 성공적으로 처리
200
: OK (단순 요청 성공)
201
: Created (요청을 성공하면 새로운 리소스가 생성되며 이 리소스는 응답의 Location 헤더 필드로 식별된다.)
202
: Accepted (요청이 접수되었으나 처리가 완료되지 않은 상태. 배치 처리 같은 곳에서 사용한다. → 요청 접수 후 1시간 뒤 배치 프로세스가 요청을 처리)
204
: No Content (서버가 요청을 성공적으로 수행했으나, 응답 페이로드 본문에 보낼 데이터가 없다.)
예를 들어, 웹 문서 편집기에서 save 버튼을 눌렀다면 응답으로 내가 저장한 내용을 굳이굳이 돌려줄 필요가 없다. 이럴 때(결과 내용이 없지만 성공 인식 가능) 204를 사용한다.
[3] 3xx - 리다이렉션
(Redirection)
: 요청을 완료하기 위해 유저 에이전트(주로 웹 브라우저)의 추가 조치 필요
📌 3xx 정리 (301~8 까지가 중요)
300: Multiple Choices
301: Moved Permanently
302: Found
303: See Other
304: Not Modified
307: Temporary Redirect
308: Permanent Redirect
🤔 리다이렉션이 뭐지?
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동한다. ➡️ 리다이렉트
리다이렉션 종류
-
영구 리다이렉션: 특정 리소스의 URI가 영구적으로 이동
ex. /members -> /users (uri 완전히 바뀜) -
일시 리다이렉션: 일시적인 변경
(주문 완료 후 주문 내역 화면으로 이동하는 것과 같은)
PRG패턴: Post/Redirect/Get
-
특수 리다이렉션: 결과 대신 캐시 사용
영구 리다이렉션
301, 308
- 리소스의 URI가 영구적으로 이동했다는 것을 알려줌. → 원래 URL를 사용하지 않으며 검색 엔진 등에서도 변경을 인지할 수 있다.
301 Moved Permanently
: 리다이렉트시 요청 메소드가 GET으로 변하고 본문이 제거될 수 있다.308 Permanent Redirect
: 301과 기능은 같으나
리다이렉트시 요청 메소드와 본분 유지 (POST로 보내면 리다이렉트도 POST를 유지한다는 것)
일시적인 리다이렉션
302, 307, 303 (세 기능은 다 같음)
- 리소스의 URI가 일시적으로 변경되었다는 것을 알려줌. 따라서 검색 엔진 등에서 URL을 변경하면 안된다.
302 Found
: 리다이렉트시 요청 메소드가 GET으로 변하고, 본문이 제거될 수 있다. → 어라, 301과 똑같네? 제거될 수도 아닐 수도 !!(근데 사실상 거의 다 변한다 ^ ^)307 Temporary Redirect
: 302와 기능은 같으나
리다이렉트시 요청 메소드와 본문이 유지된다. (요청 메소드를 변경하면 안된다 !!)303 See Other
: 302와 기능은 같으나
리다이렉트시 요청 메소드가 GET으로 변경된다.
🙋🏻♀️ 명확한 307, 303을 쓰는 것이 좋지만 실무에서는 아직 많이 302를 쓰고있다. 그것이 딱히 문제가 되지도 않기 때문 ..!
PRG: Post/Redirect/Get
우선, 일시적인 리다이렉션 예시를 생각해보자.
- POST로 주문 후 웹 브라우저를 새로고침 했을 때
이때, 새로고침은 재요청이기 때문에 중복 주문이 발생할 수 있다.
POST로 주문 후 새로고침해 중복 주문이 되는 것을 방지하려면 (클라이언트, 서버 두 쪽 다 막을 수 있다) POST로 주문 후 주문 결과 화면을 GET 메소드로 리다이렉트하면 된다.
그렇게되면 주문 후 새로고침을 해도 GET으로 조회하기 떄문에 중복 주문을 막을 수 있다. 
즉, PRG 이후 리다이렉트를 한다면 URL이 이미 POST에서 GET으로 리다이렉트 되었기 때문에 중복 주문은 막고 결과 화면만 조회할 수 있다.
🙋🏻♀️: 그래서 뭘 쓰라는 건가요?
👩🏻💻: 302는 GET으로 변할 수도 아닐 수도 있고, 307은 메소드가 변하면 안되고, 303은 메소드가 GET으로 변경되니까 알아서 맞춰 쓰시면 되겠네요.
🙋🏻♀️:
👩🏻💻: ㅋ ㅋ,, 307과 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본 값으로 사용하고 있기 때문에 자동 리다이렉션시 GET으로 변해도 된다면 302를 사용해도 좋습니다 ^ ^
기타 리다이렉션
300 304
-300 Multiple Choices: 안 씀
304 Not Modified: 진짜 많이 씀
- 캐시를 목적으로 사용
- 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬 PC에 저장된 캐시를 사용한다. ➡️ 캐시로 리다이렉트
- 304 응답은 응답에 메시지 바디를 포함하면 안 된다. (로컬 캐시를 사용해야 하기 때문)
- 조건부 GET, HEAD 요청시 사용
[4] 4xx - 클라이언트 오류, 5xx - 서버 오류
4xx (Client Error)
: 새로고침으론 복구가 불가능해 요청을 수정해 다시 보내야 함.
(클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음)
오류의 원인이 클라이언트에 !!
클라이언트가 이미 잘못된 요청을 보내고 있기 때문에 똑같은 재시도는 의미없음 !!
400 Bad Request
: 클라이언트가 잘못된 요청을 해 서버가 요청을 처리할 수 없는 상태
(요청 구문, 메시지 등등에서 오류 발생)
클라이언트는 요청을 다시 검토하고 전송해야 함.
ex) 요청 파라미터 오류, API 스펙이 맞지 않을 때
401 Unauthorized
: 클라이언트가 해당 리소스에 대한 인증(Authentication)이 필요한 상태
📌
인증(Authentication): 본인이 누구인지 확인하는 행위 (로그인자체가 안되면 인증이 안되는 것)인가(Authorization): 권한부여 (admin처럼 특정 리소스에 접근 가능한 권한같은,, 접근할 수 있는 등급을 말함)
로그인 할 수 있음 != 권한오류 메시지가 Unauthorized이지만 (이름이 아쉽 ㅜ ㅜ) 인증에 대한 부분이 맞음.
403 Forbidden
: 서버가 요청을 이해했지만 승인거부
주로 인증 자격 증명은 있지만 접근 권한이 불충분한 경우임. (admin 등급이 아닌 사용자가 로그인은 했지만, admin 등급 리소스에 접근할 때)
404 Not Found
: 요청 리소스를 찾을 수 없음
😒: 클라이언트야 나는 이런 리소스 없어 !!!!
5xx (Server Error)
: 서버 문제
서버 문제이기 때문에 재시도로 성공할 수도 있음
500 Internal Server Error
: 서버 문제로 오류 발생,
백엔드에서 발생한 애매한 오류는 그냥 500을 사용하자
503 Service Unavailable
: 서비스 이용 불가
서버가 일시적 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음.
근데 어차피 예상치 못한 오류여서 503을 보는 경우는 거의 없을껄 ,,? 🙃
