400은 Bad Request. 즉 요청이 잘못된 경우입니다.
developer.mozilla.org/en-US/docs/Web/HTTP/Status/400
400 Bad Request
The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message fr
developer.mozilla.org
이 경우는 서버가 클라이언트가 보낸 요청을 제대로 '해석'을 못하는 경우 발생합니다.(아래 에러들은 전부 서버가 클라이언트가 보낸 메시지를 제대로 해석했지만 처리를 하지 못하는 경우 발생합니다.)
409는 Conflict. "이 응답은 요청이 현재 서버의 상태와 충돌될 때 보냅니다"
developer.mozilla.org/ko/docs/Web/HTTP/Status/409
409 Conflict
HTTP 409 Conflict 응답 상태 코드는 서버의 현재 상태와 요청이 충돌했음을 나타낸다.
developer.mozilla.org
여기서 말하는 충돌은 어플리케이션에 구체적인 에러가 발생한 경우를 의미할 수 있습니다.
여기서 말하는 상태란 타깃 리소스의 현재 상태와 충돌이 난다는 의미로 볼 수 있습니다.
앞이 4인만큼 이 경우에 유저가 직접 리소스 충돌을 해소하고 나서 다시 요청을 날려야 하는 상황입니다.
그렇기 때문에 이메일 중복 체크처럼 리소스가 충돌이 되는 경우에 사용하기에 적합하다고 생각합니다.
422 Unprocessable Entity
developer.mozilla.org/ko/docs/Web/HTTP/Status/422
422 Unprocessable Entity
이 응답은 서버가 요청을 이해하고 요청 문법도 올바르지만 요청된 지시를 따를 수 없음을 나타냅니다.
developer.mozilla.org
이 경우는 content type을 서버에서 이해는 한 상태입니다. 그리고 요청 엔티티의 문법 역시 문제가 없습니다.(있다면 400 에러가 적합하다고 생각합니다) 하지만 어플리케이션의 지시사항 혹은 요청한 작업을 수행하지 못하는 상황입니다.
가령 이메일을 저장하는 상황에서 .de 도메인이 있는데, 서버에서 이 도메인 처리에 대한 로직을 제공하지 못하는 경우 이 때 422를 던져줄 수 있습니다.
혹은 요청 데이터에 대해 validation 처리를 하면서 적합하지 않은 데이터를 받았을 때 역시 이 에러를 줄 수 있습니다.
412 Precondition Failed
developer.mozilla.org/ko/docs/Web/HTTP/Status/412
412 Precondition Failed
The HyperText Transfer Protocol (HTTP) 412 Precondition Failed client error response code indicates that access to the target resource has been denied. This happens with conditional requests on methods other than GET or HEAD when the condition defined by t
developer.mozilla.org
이 에러에서 Precondition이란 HTTP의 헤더에서 사용하는 Precondition 헤더를 의미합니다.
그 중 If-Match란 precondition HTTP 헤더가 있는데, 이 헤더에 ETag를 담아서 PUT요청을 날리는 경우,
만약 수정하려는 리소스가 out of date인 경우 ETag가 일치하지 않아서 Precondition Error를 날리면서 서버에서 PUT요청을 제대로 처리하지 못한 경우입니다. 즉, If-Match는 리소스가 최신 데이터인지 ETag를 통해 확인을 한 후 최신인 경우에만 업데이트 요청을 처리하도록 하기 위한 Precondition 헤더인데, 이 Precondition 이 충족되지 않을 때 이 에러를 내려줄 수 있습니다.(아마도 클라이언트가 받는 리소스를 갱신해야 할 거 같습니다)
기타:
Precondition 헤더 중 다른 예로는 If-None-Match가 있습니다.
If-Match와는 반대로 If-None-Match는 캐시를 위해서 사용하는데.. 마찬가지로 ETag를 통해 값을 비교해서 만약 이 값이 False라면 서버에서 요청을 다시 처리하지만 True라면.. 다시 말해 ETag값을 비교해서 같다면 단지 304 Not Modified 상태 코드를 내려주기만 하는 것으로 처리를 마칠 수 있습니다. 리소스가 변경되지 않았기 때문에 어플리케이션 로직을 다시 탈 필요가 없기 때문입니다.