关于 REST 注册设计的问题

本来想 append 到之前一篇问题下面的：关于 REST authorization 授权设计的疑问，但是之前的经验发现 append 上去的内容都没人看，所以发了一个新的问题。

先理一下我的登陆流程：

1. 用户访问登陆界面，填写信息
2. web 后端校验验证码，并将 email/password 送给 api POST /authorization
3. api 校验成功之后生成 token，集中存到 redis，之后将 token 返回给 web
4. web 后端通过 session 存放 token，将其关联到用户的 cookie

此时用户处于已登陆状态，当用户想要访问需要登陆授权的资源时：

1. web 后端从 session 中取出 token，加在 GET 参数上传送给 api
2. api 拿着这个 token 去 redis 中查，从而拿到 uid
3. api 将 uid 视为当前登陆用户的 ID，并查询相关资源

这个时候有个疑问：

我的注册流程是否需要加入到 REST api 中，去 github rest api 也没找到例子，如果加入的话，应该如何设计？

本来想的注册流程：

1. 用户访问注册界面，填写信息（邮箱需要确认）
2. web 后端拿到邮箱，向邮箱中发送一份包含验证链接的邮件，并将临时注册信息和生成的校验码 checkToken 在 session 中关联起来
3. 暂时没有将临时注册信息放到库中，而是直接存到了 web 端的 session （会导致用户切换浏览器点击验证邮件无法验证，期望如此，不是设计缺陷），用户点击邮件中的链接，带着 checkToken 过来，web 拿来和 session 中的对比，一致，则将关联的临时注册信息送到 api
4. api 接收到注册信息，POST 完成新增用户的操作，生成和 /authorization 时一致的 token，关联新生成的 uid 并存到 redis，返回用户信息和 token 给 web
5. web 拿到 token，存到 session，视为已登陆

但是这里面有个问题，假设现在的注册 api 地址是 POST /register，那岂不是其他人都能访问，都可以往库里新增用户（ api 可以限制 web 端的内网 ip，但是 app 必须得公网啊）？虽然用对称加密比如 AES 给 payload 加密可以避免这个问题，但总觉得不太合理。

希望各位有过设计经验的帮忙解答一下～