닉네임 중복 확인 API

sequenceDiagram
	User -->> Server : 닉네임 중복 확인 요청
	Server -->> User : 사용 가능한 닉네임입니다.(200)
	Note over User,Server: 생략
	User -->> Server : 최종 회원가입 요청 

Loading

닉네임 중복 확인 OK가 의미하는 바

1. 그 시각을 기준으로 중복 닉네임이 없음이 보장됩니다.
2. 15분간 해당 닉네임은 선점되며 다른 유저가 해당 닉네임으로 회원가입 할 수 없습니다.

주의 하실 점

sequenceDiagram
	User -->> Server : nickname1 중복확인
	Server -->> User : nickname1 token
	note over User,Server : 15분 경과
	User -->> Server : nickname1을 통한 회원가입
	Server -->> User : 닉네임 중복 검사를 다시 수행하시오.

Loading

유저가 닉네임 중복 확인 API를 요청하고 회원가입 페이지에서 15분 이상 체류한 뒤

회원가입 요청을 보낼 경우 닉네임 중복 체크가 다시 이루어져야합니다.

유저가 같은 닉네임으로 중복 확인을 여러 번 수행하는 경우

중복 확인을 하면 서버는 해당 닉네임을 선점해놓고 발급된 닉네임 토큰으로만 회원가입이 가능하도록 설계 되어있습니다.

닉네임을 선점한 유저가 누구인지를 서버는 알 지 못하고 있기 때문에 유저가 중복 확인 버튼을 여러 번 누른다면 서버는 중복된 닉네임이라는 응답을 내려주게됩니다.

물론 해당 부분도 확인 할 수 있도록 서버에서 구현하고자 한다면 가능은 하겠지만, 닉네임을 수정하지 않고 중복 확인 버튼을 누르는 것은, 서버로 API 요청을 전송할 필요가 없기에 불 필요한 작업이라 생각해 고려하지 않았습니다.

해당 부분을 고려하여, 유저가 닉네임을 수정하지 않고 여러 번 중복 확인 버튼을 누른다면 서버와의 통신 없이 사용 가능한 닉네임임을 출력해주셨으면 합니다.

이때, 주의하실 점은 바로 직전의 닉네임만 막아주는 것이 아니라 유저가 호출했던 모든 닉네임을 저장하고 계셔야합니다.

또한 해당 닉네임의 중복 확인 요청이 15분이 지났다면 재 요청이 필요합니다.

유저가 중복 확인을 여러 번 수행했을 때 고려해야 할 점

sequenceDiagram
	User -->> Server : nickname1 중복확인
	Server -->> User : nickname1 token
	User -->> Server : nickname2 중복 확인
	Server -->> User : nickname2 token
	User -->> User : nickname1 중복 재확인
	note over User,Server : 생략
	User -->> Server : nickname1을 통한 회원가입(with nickname1 token)

Loading

위 케이스에서 보듯이 유저가 nickname1 → nickname2 → nickname1순으로 중복 확인 요청을 할 경우 마지막 nickname1은 서버 통신을 거치지 않습니다.

따라서 nickname1에 대한 토큰을 local에서 가지고 있다가 회원 가입을 수행할 때 해당 닉네임에 맞는 token을 전달해줘야 한다는 점을 고려하셔서 개발하셔야합니다.

Local에 저장할 데이터 정리.

1. 중복 요청을 보낸 기록이 있는 nickname
2. nickname에 대응되는 token
3. nickname에 대응되는 유효 기간