How to properly organize user registration and confirmation via mail in a RESTful application?

Question

RESTful API

Here is my misconception about how to organize it:
The user fills in the data, for example, in an android application, then clicks the "Register" button and data in json format (something like this { firstName: 'Aleksey', email: '[email protected] .ru', ... }) are sent to the server using an HTTP request with the POST method and URI: "/users/".
Then, based on this data, an UnverifiedUser is created on the server and stored in the unverified_users table, this object will store a token, which will also be sent to the user's mail. The server then returns a "202 Accepted" response.
The user will receive a letter with a link containing the token, but I don’t know what URI should be in this link, I know that it’s definitely not /users/{token}.
When the user follows this link, the database looks for an UnverifiedUser with the same token, if there is one in the database, then we create a full-fledged User object and save it to the database and return "201 Created".
So, as for me, the return of "202 Accepted" here is wrong, if I understand correctly, then this response signals that the server will later complete the processing of the request on its own.
Also, I don't know what URI should be in the activation link with the token, it definitely can't be /users/{token} due to the fact that such a URI is already taken for another action (user request by ID: /users/{id} ) and, in general, the token in the link is a parameter, which means that following the link initiates a GET request, and such a request should not change the state of the server, that is, it should not create a User.
The only correct solution, in my opinion, is to create an UnverifiedUser, that is, the User object will not have a property of type $isRegistered, which, I think, will cause problems in the future. Well, maybe this is not so, maybe I'm wrong and this is a bad decision. I don't know yet, we need to go a little further to find out.
Perhaps you should not adjust registration for REST at all? I xs, I'm not very good at this, I just try to study and write an application at the same time.
Also tell me, please, who should send the letter, the client or the server? It seems to me that the server.

Answer 1

Mnogabukaf and clearly visible contours of a bicycle with square wheels are seen by me in this question.
Take, for example, Laravel and see how it's done there. Modify as needed to suit your needs. For example:

api/auth/register — регистрация
api/email/verify/{user_id}/{hash} — ссылка в письме

an UnverifiedUser is created and stored in the unverified_users table

Game number 1, some field is enough email_verified = true|false.

The server then returns a "202 Accepted" response

Game number 2.

Also tell me, please, who should send the letter, the client or the server? It seems to me that the server.

It is obvious.

Answer 2

If an android, then forget about confirmation, either sms or nothing. And these confirmations do not give anything, the value of email in terms of lead generation is near zero, and 90% protection from spam is given by SMS (but in fact there are many services like https://sms-activate.ru/ru/), plus numbers can be handled by salespeople.