简体   繁体   English

REST API端点,用于通过多步骤过程更改电子邮件并更改密码

[英]REST API Endpoint for changing email with multi-step procedure and changing password

I need help for creating the REST endpoints. 我需要帮助来创建REST端点。 There are couple of activities : 有几个活动:

To change the email there are 3 URL requests required: 要更改电子邮件,需要3个URL请求:

  1. /changeemail : Here one time password (OTP) is sent to the user's mobile / changeemail:这里一次性密码(OTP)被发送到用户的手机

  2. /users/email : the user sends the one time password from previous step and system sends the email to the new user to click on the email activate link / users / email:用户从上一步发送一次性密码,系统将电子邮件发送给新用户点击电子邮件激活链接

  3. /activateemail : user clicks on the link in the new email inbox and server updates the new email / activateemail:用户单击新电子邮件收件箱中的链接,服务器更新新电子邮件

To change password : 要更改密码:

  1. /users/password (PATCH) : user submits old password and new password and system accordingly updates the new password / users / password(PATCH):用户提交旧密码和新密码,系统相应地更新新密码

Similarly, there are other endpoints to change profile (field include bday, firstname and last name) 同样,还有其他端点可以更改配置文件(字段包括bday,名字和姓氏)

after reading online I believe my system as only users as the resource --> so to update the attributes I was thinking of using a single PATCH for change email and change password and along with that something like operation field so the above two features will look like : 在线阅读之后我相信我的系统只是users作为资源 - >所以要更新属性我正在考虑使用单个PATCH更改电子邮件和更改密码以及操作字段之类的东西,所以上面两个功能将会看起来喜欢 :

For changing email : 要更改电子邮件:

  1. operation : 'sendOTPForEmailChange' 操作:'sendOTPForEmailChange'
  2. operation : 'sendEmailActivationLink' 操作:'sendEmailActivationLink'
  3. operation : 'activateEmail' 操作:'activateEmail'

For changing password : 更改密码:

  1. operation : 'changePassword' 操作:'changePassword'

and I will have only one endpoint for all the above operations that is (in nodejs) : 我将只有一个端点用于上述所有操作(在nodejs中):

app.patch('/users', function (req, res) {
  // depending upon the operation I delegate it to the respective method
   if (req.body.operation === 'sendOTPForEmailChange') {
       callMethodA();
   } else if (req.body.operation === 'sendEmailActivationLink') {
     callMethodB();
   } else if (req.body.operation === 'activateEmail') {
      callMethodC();
   } else if (req.body.operation === 'changePassword') {
      callMethodC();
   } else sendReplyError();

});

Does this sound a good idea ? 这听起来不错吗? If not, someone can help me form the endpoints for changeemail and changepassword. 如果没有,有人可以帮我组建changeemail和changepassword的端点。

Answer : 答案

I finally settled for using PATCH with operation field in the HTTP Request Body to indicate what operation has to be performed. 我最终决定在HTTP Request Body中使用带有操作字段的PATCH来指示必须执行的操作。 Since I was only modifying a single field of the resource I used the PATCH method. 由于我只修改了资源的单个字段,因此我使用了PATCH方法。 Also, I wanted to avoid using Verbs in the URI so using 'operation' field looked better. 另外,我想避免在URI中使用Verbs,因此使用'operation'字段看起来更好。

Some references I used in making this decision : 我在做出这个决定时使用的一些参考文献

Wilts answer link here 威尔茨在这里回答链接

Mark Nottingham' blog link article Mark Nottingham的博客链接文章

and finally JSON MERGE PATCH link RFC 最后是JSON MERGE PATCH 链接RFC

You should make the links that define the particular resource, avoid using PATCH and adding all the logic in one link keep things simple and use separation of concern in the API like this 您应该创建定义特定资源的链接,避免使用PATCH并在一个链接中添加所有逻辑,保持简单并在API中使用关注点分离

1- /users/otp with HTTP Verb: GET -> to get OTP for any perpose
2- /users/password/otp with HTTP Verb: POST -> to verify OTP for password and sending link via email
3- /users/activate with HTTP Verb: POST to activate the user
4- /users/password with HTTP Verb: PUT to update users password

Hashing Security is a must read, IMHO, should you ever want to implement your own user account system. 如果你想要实现自己的用户帐户系统, 哈希安全是必读的,恕我直言。
Two-factor identification should always be considered, at least as an opt-in feature. 应始终考虑双因素识别,至少作为选择加入功能。 How would you integrate it into your login scheme ? 您如何将其集成到您的登录方案中?
What about identity federation ? 身份联合怎么样? Can your user leverage their social accounts to use your app ? 您的用户可以利用他们的社交帐户来使用您的应用吗?

A quick look at Google yielded this and this , as well as this . 快速浏览一下这个 这个以及这个

Unless you have an excellent reason to do it yourself, I'd spend time integrating a solution that is backed by a strong community for the utility aspects of the project, and focus my time on implementing the business value for your customers. 除非您有充分的理由自己动手,否则我会花时间将强大的社区支持的解决方案集成到项目的实用程序方面,并将时间集中在为客户实现业务价值上。

NB: my text was too long for the comments 注意:我的评论太长了

Mostly agree with Ghulam's reply, separation of concerns is key. 大多数人都同意古拉姆的回答,关注点的分离是关键。 I suggest slightly different endpoints as following: 我建议稍微不同的端点如下:

1. POST /users/otp      -> as we are creating a new OTP which should be returned with 200 response. 
2. POST /users/email    -> to link new email, request to include OTP for verification. 
3. PUT  /users/email    -> to activate the email.
4. PUT  /users/password -> to update users password.

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM