HTTP 상태코드 소개
- 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
- 1xx: 요청이 수신되어 처리중 (informational, 거의 사용되지 않음)
- 2xx: 요청 정상 처리 (Successful)
- 3xx: 요청을 완료하려면 추가 행동이 필요 (Redirection)
- 4xx: 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 (Client Error)
- 5xx: 서버 오류, 서버가 정상 요청을 처리하지 못함 (Server Error)
- 만약 클라이언트가 인식할 수 없는 상태 코드를 서버가 반환하면?
- 2xx면 (구체적으로 모르는 코드라고 해도) 그냥 잘 됐구나 하면 됨
- 4xx면 클라이언트가 뭔가 이상한 요청을 보냈구나
- 클라이언트는 상위 상태코드로 해석해서 처리 (451 -> 4xx, 299 -> 2xx)
- 미래에 새로운 상태 코드가 추가되어도 클라이언트를 수정하지 않아도 됨
2xx - 성공
- 자주 쓰이는 200번대 코드들
- 200 OK
- 요청에 대한 응답이 성공했을 때
- 201 Created
- 주로 POST 요청에 대한 응답으로 사용
- HTTP 응답 메세지 헤더의 Location: 새로 생성된 리소스의 URI 경로를 넣어준다
- 202 Accepted
- 요청이 접수되었으나 처리가 완료되지 않았음
- 배치 처리 같은 곳에서 사용 (사실 잘 사용하지는 않음)
- 204 No Content
- 서버가 요청을 성공적으로 수행했지만 응답 페이로드 본문에 보낼 데이터가 없음
- 예시) 웹 문서 편집기의 저장 (save) 버튼 -> save 버튼을 눌러도 같은 화면을 유지해야 하고, 굳이 응답 바디가 필요가 없다.
- 200 OK
- 200만 쓰거나 200, 201만 쓰는 경우도 많다. 개발하기 전에 무엇을 어떻게 쓰자고 팀 안에서 결정해 두는 게 좋다.
3xx - 리다이렉션
- 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
- 유저 에이전트 (UserAgent): HTTP 요청을 보내는 클라이언트의 식별 정보를 담고 있는 request header의 일종. 여기서는 주로 웹 브라우저.
- 리다이렉션: 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location이 가리키는 위치로 자동으로 이동한다 (리다이렉트)
- 기존에 많이 배포되었던 링크를 변경하거나 다른 페이지로 연결되도록 하고 싶을 때 사용한다
리다이렉션의 종류:
(1) 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동- 원래의 URL을 사용하지 않음
- 검색 엔진 등에서도 변경 인지 (기존 URL을 버리고 새 URL을 쓴다)
(a) 301 Moved Permanently- 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
- POST로 보내면 본문이 손실되어 리다이렉트 이후 다시 입력해야 할 수 있음
- 보통 301을 쓴다. 실무에서는 URL (페이지)가 바뀌면 입력해야 하는 내용도 바꾸는 것이 일반적. 어차피 다 바뀜.
- 301과 기능은 같음
- 리다이렉트 시 요청 메서드와 본문 유지 (POST로 보내면 리다이렉트 하고도 POST임)
- 리소스의 URI가 일시적으로 변경
- 따라서 검색 엔진 등에서 URL을 변경하면 안됨 (!)
(a) 302 Found- 리다이렉트 시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음
- 제거될 수 있음... 이지만 보통 GET으로 바뀐다.
- 실무에서는 대부분 302를 많이 사용. 불명확하지만 이렇게 해도 큰 문제는 없어요
- 302와 기능은 같음.
- 리다이렉트 시 요청 메서드와 본문을 유지. (요청 메서드를 변경하면 안된다. MUST NOT!)
- 302와 기능은 같음.
- 리다이렉트 시 요청 메서드가 GET으로 변경 (예외 없음)
- 일시 리다이렉션: 예시
- PRG: Post/Redirect/Get
- POST로 주문 후에 웹 브라우저를 새로고침하면? 중복 주문이 될 수 있다.
- 새로고침은 마지막 요청을 새로 보낸다. (마지막 요청이 POST이기 때문에)
- 해결하기 위해서:
- POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
- 302 Found 같은 것을 반환하고 Location에 결과창의 URI를 넣는다.
- 리다이렉션 HTTP 코드를 받았기 때문에 클라이언트가 자동으로 Location으로 리다이렉트 한다. 이때는 GET을 쓴다. (자동)
- 사용자가 새로고침 해도 GET 메서드가 반복되므로 중복 주문 대신 결과 화면만 계속 나오게 된다.
- 300 Multiple Choice 안 쓴다.
- 304 Not Modified
- 캐시를 목적으로 사용함
- 클라이언트에게 리소스가 수정되지 않았음을 알려준다.
- 클라이언트는 이 코드를 받으면 로컬 PC 저장된 캐시를 재사용한다. (캐시로 리다이렉트한다.)
- 304 응답은 응답에 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하니까)
- 조건부 GET, HEAD 요청 시에 사용
4xx - 클라이언트 오류, 5xx - 서버 오류
400대 오류
- 클라이언트 오류
- 오류 원인이 클라이언트에게 있음 (잘못된 문법 등)
- 클라이언트가 보낸 요청에 이미 오류가 포함돼 있으므로 서버가 요청을 수행할 수 없음
- 500대 오류와의 중요한 차이: 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 똑같이 재시도해도 실패함
- 재시도해서 성공하려면 요청을 수정해야 함.
- 400 Bad Request
- 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
- 요청 구문, 메세지 등에 오류
- 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때 (숫자를 보내야 하는데 문자를 보내거나...)
- 401 Unauthorized
- 인증 (Authentication)되지 않음 (오류 메세지 아쉽... 헷갈리지 말 것)
- 401 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명해야 함
참고: 인증(Authentication)은 로그인 할 수 있는지 없는지 확인, 인가 (Authorization)는 로그인 한 뒤 권한을 확인
- 403 Forbidden
- 서버가 요청을 이해했지만 승인을 거부
- 인증 자격은 증명했지만 접근 권한이 충분하지 않은 경우
- 404 Not Found
- 요청 리소스가 서버에 없음
- 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때 (403이 나오면 있긴 한데 니가 접근 못한다는 뜻)
- 이게 왜 클라이언트 오류냐면, 서버는 이런 거 안 가지고 있는데 클라이언트가 잘못된 요청으로 접근하려고 하는 것이기 때문에
500대 오류
-
서버 오류
- 서버 문제로 오류 발생 (오류 원인이 서버에 있음)
- 서버에 문제가 있기 때문에 같은 요청으로 재시도하면 성공할 수도 있음 (!)
- 서버가 복구되거나 등등
-
500 internal Server Error
- 애매하면 요거
- 말그대로 서버 내부 에러
-
503 Service Unavailable
- 서비스 이용 불가
- 서버가 일시적인 과부하 또는 예정된 작업(서버 다운)으로 잠시 요청을 처리할 수 없음
- Retry-After 헤더 필드로 얼마 뒤에 복구되는지 예상 시간을 응답에 포함해서 보낼 수도 있음
-
웬만하면 500대 에러를 발생시키면 안됨.
- 진짜 서버에 무슨 문제가 생겼을 때 에러를 보내야 됨.
- 모니터링 할 때도 500대 에러는 심각한 서버 에러로 간주함.
- 비즈니스 로직 상 예외 처리가 된 것은 정상 동작임. 로직이 알아서 처리해야 함.
- NPE나 DB가 내려가거나 요런 심각한 서버 장애가 발생했을 때만 500번대 에러를 내려줘야 한다.
