我们有一个API,可以向用户的手机号码发送验证码。 API是:
POST /api/users/verification/start/
{
"mobile": "9849735434"
}
以上API返回以下回复:
{
"isVerified": false
}
如果回复是“isVerified”:true,我们不会向用户的手机发送验证码。如果是假,我们发送代码。
目前,所有这些都适用于手机号码。我们希望基于(移动设备+设备)使其更安全。
为实现此目的,我们在客户端计算机上存储用户标识cookie,并且我们计划在此基础上识别设备。如何针对这一新要求修改API?几乎没有办法:
我们应该如何设计此类API以根据移动设备和设备验证用户?
答案 0 :(得分:0)
我会修改现有的API以适应新的要求,这是我在修改时要做的重要事情。
1)每当您创建任何API时,总是从客户端传递“版本”,您将知道要执行的代码部分。 例如,假设您的移动用户有2个不同版本的应用程序,一次此版本之前的另一个版本。让用户运行版本控制都很有帮助。
2)从客户端传递“设备类型”以检查客户端是否为移动/标签或其他,这将具有多种优势首先您将知道手机/网络中有多少用户群,另一个优点是您可以自定义相应的输出大小,因为与移动应用相比,网络将提供更多信息。
现在您已拥有设备和版本信息,您只需在现有API中编写条件即可。一旦您认为没有旧版本使用,我们就可以淘汰那部分API。
希望这是有道理的。
答案 1 :(得分:0)
希望这会对您有所帮助,您可以修改代码并遵循一些客户端和服务器步骤。
客户端
第1步。
服务器端
第2步。
第3步。
客户端
第4步。
答案 2 :(得分:0)
有不同的选择。
如果您想使用Cookie,为什么还需要单独的API?如果客户端有cookie,请让客户端将此cookie作为cookie发送。您的服务可以在需要时分析cookie并决定进一步的步骤。
如果您无法发送Cookie,则第一种方法不适合您: 设备不应该知道,从您的服务的角度来看,它是什么类型。这就是为什么我建议使用两种服务 - 一种不使用cookie,另一种使用cookie。
你说“RESTful”。在当前形式中,您的服务不是RESTful。
A)使用动词使服务不是RESTful。例如,将其重命名为
"POST /api/users/verification/"
B)在一个操作中混合两个操作:检查客户端是否已通过身份验证并启动身份验证过程。将其分为两部分: 要检查客户端是否经过身份验证:
"GET /api/users/verification/mobile/9849735434"
开始身份验证:
"POST /api/users/verification/mobile/9849735434"
对于POST,在这种情况下你不需要身体。