[Web] HTTP status 상태코드

잘 작성된 블로그가 있어서, 공부할 겸 정리해보았다.
일단은 4xx 위주로 알아봤는데 추가로 api를 만들때마다 이 글에 붙여넣어야 겠다.

REST API 관점에서 바라보는 HTTP 상태 코드(HTTP status code)

출처: https://sanghaklee.tistory.com/61 [이상학의 개발블로그]

HTTPStatus code

• 4xx Client errors : 클라이언트의 요청이 유효하지지 않아 서버가 해당 요청을 수행하지 않았다는 의미
  • 400 Bad Request
    • 클라이언트의 요청이 유효하지 않다.
    • 필수, 유효 범위, 패턴등에 대한 검증의 결과
    • 400 상태 코드로만 응답하기 보다는 파라미터의 위치, 사용자의 입력값, 에러 이유를 명시하는것이 좋다

    • 1. 'name' must be String, input 'name':'123'
      2. "errors": [ { location: body, param: name, value: 123, error: typeError, msg: must be String }] // ""생략함
      3. 1+2 같이 

  • 401 Unauthorized
    • 클라이언트가 권한이 없기 때문에 작업을 진행할 수 없다.
    • 권한(authorized)보단 인증(authenticated)에 관한 의미이다. 비인증상태로 자원을 이용할 수 없다
  • 403 Forbidden
    • 클라이언트가 권한이 없기 때문에 작업을 진행할 수 없다.
    • 이때는 권한(authorized)에 관한 내용
    • 회원기능이 있을 때 401은 로그인이 필요한상태 / 403은 로그인 후 뭔가를 못하게되는 상태 라고 구분하면 될 것 같다.
  • 404 Not Found
    • 클라이언트가 요청한 자원이 존재하지 않다.
    • _경로_가 존재하지 않거나, _자원_이 존재하지 않거나
    • /user/:id 를 요청했을 때 id에 해당하는 값의 사용자가 없다면? -> id에 숫자값을 요청했기 때문에 400이 아닌 404이다.
  • 405 Method Not Allowed
    • 해당 자원은 존재하지만 post, get, put, delete 등 메소드가 존재하지 않을 때
    • options 메소드, HTTP header의 allow와 연관
    • 경우에 따라 자원부족의 404와 의미가 비슷해질 수 있는데, 쓰임새있게 써야한다.
  • 409 Conflict
    • 클라이언트의 요청이 서버의 상태와 충돌이 발생할 경우
    • 앞의 코드에 속하기 애매한 상황들, 그중에서도 규칙을 정해서 비즈니스 로직상 모순인 경우
    • 이유를 명시해주는것이 좋다.
• 5xx Server errors : 서버 오류로 인해 요청을 수행할 수 없다.
  • API를 사용하는 클라이언트에게 5xx 상태코드는 나타내지 않아야한다.