Question

我们已将商品网站归类为我们没有登录的网站，但用户可以查看其他用户列出的商品。要查看其他用户的详细信息，他们必须提供其联系详细信息。要验证用户是否提供了正确的手机号码，我们会将OTP代码发送回该号码。 API流程如下：

1）//当用户填写表单以获取特定股票的卖家详细信息时要点击的API（这需要“stockId”和“mobile”作为输入）：

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

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

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

如果尚未验证“mobile”，则回复（响应代码：403）：

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

2）用户在移动设备上收到的OTP再次向同一个主要API发回请求：

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

如果OTP正确，它会回复卖家详细信息。如果提供的OTP不正确，则响应为：

{
  "Incorrect OTP."
}

我发现此API设计中几个问题：

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

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

Answer 1

简单回答：否。

出于某种原因，它被称为单一责任原则。

在您的公共API中允许多个职责意味着API“端点”必须理解为每个方面“分派”到“正确”实现的不同职责。或者，您允许双重责任API设计通过提供实现的单一内容来损坏您的实现。

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

在您的情况下，用户执行：