이번 프로젝트를 진행하며 API 문서를 만들다
회원가입 POST 요청을 보냈을 때 이미 등록된 이메일이나 닉네임일 경우 응답 status code는 어떤 걸 해야할 지 고민이 되었다.
이전의 프로젝트에서는 팀원들과 협의해서 200 OK로 다 응답을 보내고 응답 body에서 처리하도록 했었다.
W3C 문서와 위키 백과를 보면서 한번 고민해보았다.
400 Bad Request
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
처음에는 잘못된 요청을 보낸 것이라 생각하고 400번으로 보내야하는 걸까 생각했는데, 400번은 잘못된 구문으로 요청을 이해할 수 없을 때 보내는 응답이라고 한다. 회원가입 요청 문법 자체에는 문제가 아니라서 요청 자체는 이해할 수 있기 때문에 적합하지 않은 듯 하다.
인증 Authentication
401과 403을 보기 전에 인증과 인가에 대해서 알아야한다.
사용자가 누구인지 확인하는 절차
ex) 로그인, 회원가입
인가 Authorization
인증된 사용자에 대한 자원 접근 권한 확인
ex) 사용자는 다른 사람의 글은 수정해선 안된다. 본인의 글은 수정할 수 있다.
401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].
401은 사용자가 인증되지 않았을 때 발생하는 에러라고 한다.
인증되지 않았다는 의미는 사용자가 요청시에 인증헤더를 포함하지 않았을 때를 의미한다.
예를 들어 로그인을 하지 않은 익명의 사용자가 글을 작성하거나 마이페이지를 조회하려고 할 때 401에러를 반환한다.
이런 의미로 볼 때 401은 권한없음(Unauthorized)라는 의미보다는 인증안됨(Unauthenticated)에 더 가깝다.
회원가입은 보통 요청 시에 아이디/패스워드 혹은 이메일/패스워드 같은 내용만 전달하면 된다. 인증을 하는 과정 자체이지 인증이 필요한 요청이 아니다. 401과는 맞지 않는 듯하다.
403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
이 경우는 서버가 사용자의 요청은 이해했지만 권한을 갖고있지 않아 거부하는 상황이다.
예를 들어 로그인은 한 사용자가 다른 사람의 글을 수정하려고 할 때가 있다.
즉, 인가가 실패했을 때의 경우 사용한다.
409 Conflict
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
고민 끝에 409 conflict..!
409는 리소스의 현재 상태와 충돌하여 요청을 완료할 수 없을 때 사용한다. 그래서 사용자가 충돌을 해결하고 요청을 다시 제출해야한다고 한다.
닉네임이라는 리소스가 이미 저장된 상태에서 중복해서 요청을 하니 사용자는 닉네임을 다시 고쳐서 요청을 해야한다. 그렇기 때문에 409가 가장 적합하다고 생각한다.
참고 문헌
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
https://ko.wikipedia.org/wiki/HTTP_상태_코드
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_client_errors
