상태 코드는 시간이 지날 수록 계속해서 증가하고 있습니다.
참고 하시기 편하도록 링크 남겨둡니다.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

제가 작성하는 내용은 주로 사용되는 상태코드만 요약하여 작성하였습니다.
개인적인 이해를 바탕으로 작성했기에 잘못된 정보가 있을 수 있습니다.

2xx Success

서버가 요청을 성공적으로 처리하였음.

200 : Ok

클라이언트 요청이 성공적으로 처리됨.

2xx대 의 모든 상태 코드를 200 으로 작성해도 문제가 되진 않는다.
허나, 클라이언트에게 세분화된 정보를 주기 위해 다양하게 표현하는 것을 권장하는 편이다.

(특히 구분 하면 좋은 것이 204 이다. 자세한 설명은 아래 참고)

201 : Created

클라이언트 요청을 성공적으로 처리하고 새로운 리소스를 생성하였다.

주로 post 요청에 자주 쓰이는 상태 코드이다.
(put 필요한 경우 쓰이기도 한다.)

202 : Accepted

클라이언트 요청은 받아드렸으나 응답을 뒤로 미룸.
fs 혹은 원하는 데이터를 구하고자 시간이 지연되는 작업에 대해 클라이언트에게 우선적으로 응답하는 상태 코드.

작업의 완료 여부를 callback을 통해 반드시 나타내주어야 한다.
ex) "다운로드가 완료되었습니다" 등의 팝업창

204 : No content

클라이언트의 요청을 통해 성공적으로 해당 리소스가 삭제됨.

4xx Client error

클라이언트 요청이 올바르지 않아 서버가 작업을 수행할 수 없음.

400 : Bad request

클라이언트 요청이 유효하지 않아 작업을 진행할 수 없음.

4xx 상태 코드에서는 어떤 부분이 잘못되었는지에 대한 명확한 예외처리가 필요하다.
대부분의 api는 응답 전 클라이언트 요청에 대한 유효성 검사를 실시하는데,
어플리케이션의 요구에 맞지 않는 요청이 전해진다면 서버는 자체적으로 작업을 중단하게 된다.
클라이언트가 다시금 올바르게 요청을 할 수 있도록 어떤 부분이 문제가 되었는지 메시지를 남겨주는 것이 좋다.

흔히 쇼핑몰 가입화면을 생각해보자.

필요한 정보를 작성하는 가운데, 클라이언트가 본인의 이름을 작성하지 않는다면
이름을 반드시 작성해주세요 라는 팝업창이 뜰 것이다.
이러한 명확한 예외처리 없이 잘못된 요청이에요 라고 뭉뚱그려 설명한다면 문제를 인지하지 못한 유저 는 문제를 해결하기 위해 불필요한 작업까지 반복하여 요청하게 될 것이다.

401 : Unauthorized

올바르지 않은 요청으로 유저가 인증 받지 못했음을 나타내는데 쓰이는 상태 코드

401 과 403 을 이해하기 위해서는 인증 (authentication) 과 인가 (authorization)에 대해 알고 넘어가야 한다.

• 인증 - 클라이언트의 정보가 유효하여, 앱 내에서 가지게 되는 직책을 말하는 것이고
• 인가 - 인증된 클라이언트만 요청할 수 있는 범위들을 말한다.

쇼핑몰 로그인 화면을 생각해보자.

로그인을 하면 해당 쇼핑몰 서버는 필요한 요청들을 확인하고 인증된 사용자라 판단한 후,
customer 라는 직책이 주어지게 된다.
우리는 customer 라는 인증을 받았기 때문에 닉네임을 변경하거나, 프로필 사진을 삭제하거나, 배송주소를 변경하는 작업들을 할 수 있게 된다. (인가의 확장)

403 : Forbidden

클라이언트의 인가 범위를 넘어서는 요청에 대해 사용되는 상태 코드이다.

user 와 admin 을 구분하기 위해 많이 사용된다.
늦은 새벽 개발자가 앱의 개선 작업을 위해 로그인을 중단시키는 경우를 자주 보게 되는데 이것 역시 403 상태 코드의 일종이다.

작업환경을 만들기 위해 admin(관리자) 만 활동이 가능한 상태로 만들어 모든 클라이언트의 요청을 금지 시키는 것이다.

404 : Not found

서버가 해당 데이터를 찾지 못해 나타내는 상태코드

크게 2가지로 구분할 수 있다.

• 서버 내에 해당 라우터가 존재하지 않는 경우.
• 해당 라우터에 리소스가 없는 경우.

409 : Conflict

올바르지 않은 요청으로 서버에서 충돌으로 일어나는 경우 사용되는 상태코드

ID와 같은 unique-data를 검증에 대한 응답으로 자주 쓰이는 상태코드이다.

서버 내에서의 충돌을 명확히 설명하기가 어려우나 굳이 표현하자면,
이미 데이터베이스에 존재하는 유저 이메일 계정을 통해 다시금 계정 가입 요청을 수행한다면,
"중복된 이메일 끼리 서로 충돌했다" 표현 할 수 있겠다.

5xx : internal Error

개발 시 예상하지 못한 error

개발자 내에서 접근 하여 다룰 수 있는 예외처리 외에 다른 error 도 존재한다.
제일 대표적인 것이 api를 통한 정보 접근을 통한 error 인데, 서버의 올바른 로직과 클라이언트의 요청에도 불구하고 api 나 라이브러리 등 서드파티가 작업을 수행하지 못해 일어나는 error들을 다루고자 생성된 상태코드이다.

언어 마다 이러한 error에 대해 표현이 다르긴 하나 보통 uncatched, unexpected, uncaughted 등 (다루지 못한, 예상하지 못한) 으로 표현되곤 한다.