Я настраиваю API для приложения.Когда приложение открывается в первый раз, пользователи могут войти или зарегистрироваться.
Для входа в систему я подумал о настройке конечной точки /tokens, где запрос содержит email и password, иответ содержит access_token, refresh_token, expires_in и token_type (что на данный момент всегда является Носителем).Эту же конечную точку можно использовать, передавая только refresh_token, чтобы получить новый access_token, а затем возвращает те же свойства (за исключением refresh_token).Это кажется нормальным, но так ли это?
Для регистрации все не так ясно.Я настроил конечную точку /users, где запрос содержит все детали, необходимые для регистрации.Первоначально я сделал это возвращение 204, а затем клиент должен был бы сделать второй запрос к /tokens, но затем я понял, что если второй запрос не удался, все может зависнуть, так как пользователь был создан, но вход в систему не состоялся,Тогда я подумал, что бэкэнд также сгенерирует токен и ответит 201 и той же полезной нагрузкой, что и запрос к /tokens.Это, однако, не показалось слишком RESTful, поскольку возвращаемый ресурс не является пользователем, несмотря на вызов /users.Тогда я подумал, что, может быть, мне удастся создать токен и ответить заголовком 204 и Location, но проблема в значительной степени аналогична первой ситуации (в этом случае пользователь может застрять, если произойдет сбой GET в местоположении).В конечном счете, я не вижу способа избежать «застрявшей» проблемы, если я не выполню все операции (создание пользователя и токена) в одной транзакции и отвечу этим.Каков наилучший способ сделать это?