REST API：单个API是否应该承担多重责任？

我们已将商品网站分类，我们没有登录，但用户可以查看其他用户列出的产品。要查看其他用户的详细信息，他们必须提供他们的联系方式。为了验证用户是否提供了正确的手机号码，我们将OTP代码发送回该号码。该API流程是这样的：REST API：单个API是否应该承担多重责任？

1）//当用户填写表单以获取特定股票的卖方详情（此预计“stockId”和“移动”作为输入）被打API：

POST /api/lead/ 
{ 
    "stockId":123, 
    "mobile":9890384328 
}

如果 “移动” 已被验证API的响应（响应代码：200）：

{ 
    "sellerName": "xyz", 
    "sellerMobile": "+123232312", 
    "sellerAddress": "21, park street, new york" 
}

回应，如果 “移动” 尚未验证（响应代码：403）：

{ 
    "OTP verification required. OTP is sent to the mobile number." 
}

2）用户发送回请求再次与在移动接收的同一导API OTP：

{ 
     "sellerName": "xyz", 
     "sellerMobile": "+123232312", 
     "sellerAddress": "21, park street, new york", 
     "otp": 1234 
}

它发送回卖方细节响应如果OTP是正确的。如果OTP提供的是不正确的，反应是：

{ 
    "Incorrect OTP." 
}

我看到在这个API设计的几个问题：

这个API做大量的工作，即返回回卖方详情，返回回OTP的，验证OTP等。我们可以轻松地将OTP相关功能分解为其他一些API。例如，用于生成OTP的一个API，即GET/api/otp /，用于验证OTP的其他API，即POST api/verifyotp /。这会增加来自客户端的API调用的数量，即，如果号码未被验证，则第一客户端将启动POST lead API，客户端将会击中OTP API。要通过OTP验证，它将调用verifyOTP api。如果得到验证，它会调用潜在客户API来获取卖家详细信息。所以，基本上它使用上述方法进行了4次API调用与2次API调用。
这是对HATEOS的投诉，它建议“REST客户端通过简单的固定URL进入REST应用程序，客户端可能采取的所有将来的操作都是在从服务器返回的资源表示中发现的。

有人可以建议哪种方法更好吗？

来源

2017-08-30 maverick

简单的回答：没有。

它被称为单责任原则的原因。

在您的公共API中允许多个责任意味着API“端点”必须理解不同的责任，以便为这些方面中的每一个“派发”到“正确”实现。或者您可以通过提供该实现的单一事物来允许您的双责任API设计损坏您的实施。

此外：当你有不同的责任时，OK /错误返回代码的范围变得更加复杂。这使得“一切”变得更加困难。为您编写测试 - 但也为使用您的API的客户。

在你的情况下，用户做：

使用/ API /导致第一
被告知关于 “未验证”
使用OTP生成API来获取验证码
以再使用特定的OTP API提交验证码
到再使用/ API /再次引发

来源

2017-08-30 08:44:06 GhostCat

所以你建议先打/ api/lead，如果返回未验证，客户端应该打到OTP API，然后是OTP验证API，如果它符合OTP，则客户端再次点击/ api/lead。正确？ – maverick

我认为这是我的答案的本质，是的。相应地更新我的答案。 – GhostCat

一件事 - 在OTP验证步骤中，我们可以以某种方式添加一些回调（由客户端传递），即如果验证了OTP，则服务器在内部启动对回调的呼叫。在OTP验证代码API步骤的情况下，我们将/ api/lead /传递给服务器。如果其正确的OTP，服务器将把请求重新路由到/ api/lead /？我们可以这样做吗？ – maverick

REST API：单个API是否应该承担多重责任？

回答

相关问题