HTTP 상태 코드

상태 코드는 매우 많으므로 어떤 걸 쓸지 내부적으로 정리하는 작업이 필요하다.

만약 라이언트가 인식할 수 없는 상태코드를 서버가 반환하면, 클라이언트는 상위 상태 코드로 해석해서 처리한다.

1xx (Informational)

• 요청이 수신되어 처리 중
• 거의 사용되지 않음

2xx (Successful)

• 클라이언트의 요청을 성공적으로 처리
• 200을 가장 많이 사용하며, 201을 사용하는 경우도 꽤 있다.

200 OK

• 요청 성공
• 가장 많이 사용하며, 이것만 사용하는 경우도 많다.

201 Created

• 생성된 리소스는 응답의 location 헤더 필드로 식별

Location: /board/1
{
	"title":"first"
}

• 200 다음으로 많이 사용된다.

202 Accepted

• 요청이 접수는 되었으나 처리가 완료되지는 않음
• 배치 처리에서 주로 사용

204 No Content

• 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
• 웹에서 저장버튼을 눌렀을 때 화면은 유지되어야 하지만, 본문 내용을 보내주지는 않아도 될 때, 204 코드를 통해 요청이 성공했음을 인식할 수 있다.

3xx (Redirection)

• 요청을 완료하기 위해 유저 에이전트(주로 브라우저)의 추가 조치가 필요
• 301부터 308까지 많이 사용한다.
• 웹브라우저는 3xx 응답 결과에 location 헤더가 있으면 그 위치로 자동 이동한다. (redirect)

---

리다이렉션의 종류

(1) 영구 리다이렉션

• 특정 리소스의 URI가 영구적으로 이동, 원래 URL를 사용하지 않으며 검색 엔진에서도 변경 인지
• 301(불명확), 308(명확)
• 301보다는 308을 쓰며, 둘 다 사용하지 않는 곳이 가장 많음

(2) 일시 리다이렉션

• 일시적인 변경 (요청 완료 후 요청 전으로 이동)
• 따라서 검색 엔진에서 URL를 변경하면 안 됨.
• 302(불명확), 307(명확), 303(명확)
• PRG(Post/Redirect/Get) 요청 완료 후 새로고침을 하면 중복 요청이 될 수 있음, 요청 완료 후 새로고침 시 결과 페이지를 get으로 읽어오도록 구현해야함 (동일 요청 번호가 들어오면 서버에서 막는 코드도 필요함)

(3) 특수 리다이렉션

• 결과 대신 캐시를 사용
• 304

(4) 기타 리다이렉션

• 300

---

300 Multiple Choices

• 거의 사용하지 않음
• 리디렉션 상태 응답 코드는 요청에 가능한 응답이 두 개 이상 있음을 나타냄
• 가능한 응답 중 하나를 선택할 수 있는 표준이 부재하여 거의 사용하지 않음

301 Moved Permanently

• 리소스가 완전히 변경되어 다른 리소스를 location으로 알려줌 (영구 리다이렉션)
• 새로운 location으로 이동하면서 요청 메소드가 get으로 변하고 본문이 제거될 수 있음
• 같은 메소드를 보낼 것이라고 기대하고 만든 스펙이지만 브라우저들이 메소드를 바꾸도록 구현해버려서 http 스펙이 변경됨
• 결과적으로 301보다는 308을 쓰며, 둘 다 사용하지 않는 곳이 가장 많음

302 Found

• 새로운 location으로 이동하면서 요청 메소드가 get으로 변하고 본문이 제거될 수 있음
• 명확하려면 307이나 303을 사용해야 하지만 현실적으로 302 사용 빈도가 제일 많음

303 See Other

• 무조건 메소드가 get으로 변경됨 (명확한 변경이 필요할 때 사용)

304 Not Modified

• 캐시를 목적으로 사용
• 클라이언트에게 리소스가 수정되지 않았음을 알려줌. 클라이언트는 캐시로 리다이렉트(재사용)
• 응답에 메시지 바디를 포함하면 안 됨 (로컬 캐시를 사용할 것이므로)
• 조건부 get, method 요청 시 사용

307 Temporary Redirect

• 302과 유사하지만 요청 메소드와 본문이 유지됨

308 Permanent Redirect

• 301과 유사하지만 요청 메소드와 본문이 유지됨

4xx (Client Error)

• 클라이언트의 요청에 잘못된 문법 드응로 서버가 요청을 수행할 수 없음
• 오류의 원인이 클라이언트에 있음
• 클라이언트가 아무리 재시도를 해도 계속 실패함

400 Bad Request

• 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
• 서버에서 철저하게 스펙 분석을 통해 validation을 하고 알려줘야함
• 클라이언트는 요청 구문, 메시지를 다시 검토해서 재시도

401 Unauthorized

• 클라이언트가 해당 리소스에 대한 인증이 필요함
• 응답에 www-authenticate 헤더와 함께 인증 방법을 설명
• 주의 401은 이름은 인가지만 기능은 인증처럼 동작하고 있음
  인증(authentication): 본인 확인
  인가(authorization): 권한 확인
• 가장 많이 사용

403 Forbidden

• 서버가 요청을 이해했지만 승인을 거부함
• 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
• 권한이 없는 리소스에 접근하는 경우

404 Not Found

• 요청 리소스를 찾을 수 없음
• 요청 리소스가 서버에 아예 없는 경우
• 또는 클라이언트가 권한이 부족한 리소스에 접근했는데 해당 리소스를 숨기고 싶을 때

5xx (Server Error)

• 서버 문제로 오류 발생
• 서버의 일시적 장애로 인해 에러가 난 경우 재시도하면 요청이 성공할 가능성 있음
• 런타임 예외(null point exception)나 DB 접속 오류 등등

500 Internal Server Error

• 서버 오류
• 서버 내부 문제로 오류 발생
• 백엔드 내부의 자잘한 에러는 대부분 500 반환
• 가장 많이 사용
• 500 에러 발생 시 모니터링 툴이 돌아감
• 비즈니스 로직 상 예외 케이스가 발생해서 서버에서 들어온 경우 500을 보내면 안 됨 (프로세스 자체는 정상적이기 때문, 그건 서버의 책임이 아님)

503 Service Unvailable

• 서비스 이용 불가
• 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
• retry-after 헤더 필드로 언제 복구되는 지 안내할 수 있으나, 보통 예측할 수 없기 때문에 500을 보내는 경우 많음