📌 이 포스팅에서는 HTTP의 상태 코드에 대해 정리하였습니다.
🔥 HTTP 상태 코드란?
🔥 2xx : 성공
🔥 3xx : 리다이렉션
🔥 4xx : 클라이언트 오류
🔥 5xx : 서버 오류
✔️ 우리가 에러가 발생됬을 때, 에러 메시지가 나타나듯이 현재 HTTP의 통신 상태가 어떤지 약속된 상태 코드 번호를 통해 알 수 있다. 이 HTTP 상태코드는 100번대, 200번대, 300번대, 400번대, 500번대가 있다.
✔️ 400대 상태코드는 클라이언트에서 잘못된 요청이 이뤄졌기 때문에 같은 요청을 해도 변함없는 오류가 발생되지만, 500대 상태코드는 서버의 문제이기 때문에 서버의 내부 문제가 해결되었다면 재요청 시 정상적인 응답을 받을 가능성이 존재한다.
🔎 1xx(Informational) : 클라이언트의 요청이 수신되어 처리 중, 실제 거의 사용되지 않음
🔎 2xx(Successful) : 클라이언트의 요청 정상 처리
🔎 3xx(Redirection) : 클라이언트의 요청을 완료하려면 추가 행동이 필요
🔎 4xx(Client Error) : 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 👈 클라이언트 오류
🔎 5xx(Server Error) : 서버 내부의 문제로 서버가 요청을 처리하지 못함 👈 서버 오류
✔️ "200 OK"는 클라이언트의 요청을 정상적으로 처리한 뒤, 응답할 때 반환된다.
✔️ "201 Create"는 클라이언트의 요청으로 서버에서 resource를 생성했을 때 응답 받을 수 있고, 보통 POST로 요청했을 때 반환된다. 생성된 resource는 응답의 Location 필드로 식별 가능하다.
✔️ 클라이언트의 요청이 서버에 정상적으로 접수되었으나, 처리가 완료되지 않은 상태에는 "202 Accepted"가 반환된다.
✔️ 예를 들어, 1시간 뒤에 어떤 프로세스를 처리하라는 요청일 경우에 서버가 이 요청을 정상적으로 접수하였을 때 반환된다.
✔️ 서버가 클라이언트의 요청을 성공적으로 수행했지만, 응답으로 보내줄 body 데이터가 없는 경우 "204 No Content"가 반환된다.
✔️ 예를 들어, 클라이언트가 저장버튼을 눌렀을 때도 같은 화면을 유지해야하는 상황이면, 저장은 되었지만 돌려줄 데이터가 없을 때 확인할 수 있다.
✔️ 리소스의 URI가 영구적으로 이동하여 원래의 URL을 사용하지 않을 때 반환된다.
✔️ 이 때 "301 Moved Permanently"와 함께 Location 필드에 새로운 주소를 서버로부터 함께 전달받게되는데 클라이언트는 새로운 URI로 자동으로 접근한다. 최초 POST로 요청되었다해도 GET으로 변하여 리다이렉트되기 때문에 본문은 제거된다.
✔️ 결과적으로 처음 URI에 접근할 때 입력해서 전달했던 Body 내용이 모두 사라져버리기 때문에 클라이언트는 리다이렉트된 곳에서 처음부터 다시 입력을 시작해야한다.
✔️ 리소스의 URI가 일시적으로 변경되었을 때, 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다. 반드시 GET으로 변하는 것은 아니지만 대부분 GET으로 변하고 대부분 "302 Found"를 사용한다.
✔️ 리소스의 URI가 일시적으로 변경되었을 때, "303 See Other"을 반환받게 된다. "302 Found"와 차이점은 리다이렉트 시 요청 메서드가 반드시 GET으로 변한다는 것이다. 이에 리다이렉트 시에 HTTP 매서드가 반드시 GET으로 요청되야할 때 사용된다.
✔️ "304 Not Modified"는 캐시 목적으로 사용하고, 클라이언트에게 resource가 수정되지 않았음을 알려주기 위해 사용한다.
✔️ 클라이언트가 "304 Not Modified"을 응답 받았을 때 로컬PC에 저장된 캐시를 재사용하여 리다이렉트 한다.
✔️ 또한 "304 Not Modified"는 로컬 캐시를 사용해야하기 때문에 서버에서 응답할 때 Body를 아무 것도 넣지 않는다. 일반적으로 조건부 GET, HEAD 요청 시 사용한다.
✔️ 리소스의 URI가 일시적으로 변경되었을 때, "307 Temporary Redirect"를 반환받고 리다이렉트 시 요청 최초 서버로 요청됬던 메서드와 Body 유지를 유지한다.
✔️ 즉, POST보내면 리다이렉트 시에도 POST로 보내지고, GET으로 요청되었을 땐 리다이렉트 시에도 GET으로 요청된다. 이에 HTTP 매서드가 변하면 안될 때 사용된다.
✔️ 301처럼 리소스의 URI가 영구적으로 이동하여 원래의 URL을 사용하지 않을 때 반환된다. 301과 유사지만 차이점은 POST의 요청을 리다이렉트시에도 유지하기 때문에 Body의 데이터도 그대로 리다이렉트된 URI에 전달한다.
✔️ 다만, 실무적에서 URI가 바뀌었다는건 새로운 URI에서 클라이언트에서 서버로 전달될 데이터(Form양식의 변경 등)가 기존 URI와 불일치할 가능성이 높기 때문에 실제로는 크게 사용되지 않는다.
✔️ "400 Bad Request"는 요청 구문, 메시지 등이 클라이언트의 잘못으로 서버에서 처리할 수 없을 때 반환되는 상태 코드다.
✔️ 이에 클라이언트는 요청 내용을 다시 검토해야한다. 보통 parameter가 잘못되었거나, API 스펙이 불일치할 때 보게된다.
✔️ "401 Unauthorized"는 클라이언트가 해당 resource에 대한 인증이 필요할 때 반환되는 상태 코드다. 즉, 누구인지 로그인이 되지 않은 상태에서 resource에 접근할 때, 발생한다.
✔️ 이 상태 코드를 서버에서 클라이언트로 전달할 때는 WWW-Authenticate Header와 함께 인증 방법을 설명해주어야 한다.
✔️ "403 Forbidden"은 서버가 요청을 이해했지만 승인을 거부할 때 발생되는 상태 코드다. 즉, 누구인지 로그인은 되었지만 resource에 접근하기에는 권한이 부족할 때 반환한다.
✔️ "404 Not Found"는 요청 resouce가 서버에 없거나 또는 권한이 없는 클라이언트의 접근을 막기 위한 방편으로 사용한다.
✔️ "500 Internal Server Error"는 서버 내부에서 발생한 오류를 처리할 때 보편적으로 사용된다.
✔️ "503 Service Unavailable"는 서버가 일시적으로 과부하가 되거나, 잠시 서버를 다운 시켰을 때 사용된다. Retry-After Header 필드로 얼마 뒤에 복구되는지 안내할 수 있다.