api - REST API : Should single API have multiple responsibilities?

Question

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

//当用户填写表单以获取特定股票的卖家详细信息时要调用的 API(这需要“stockId”和“mobile”作为输入):

发布/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."
}

用户使用在移动设备上收到的 OTP 再次将请求发送回相同的潜在客户 API:

请求有效载荷:

{
  "stockId": 123,
  "mobile": 9890384328,
  "otp": 1234
}

如果 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 应用程序。客户端可能采取的所有 future 操作都在从服务器返回的资源表示中发现。”

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

Answer 1

简单回答:没有 .

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

在您的公共(public) API 中允许多个职责意味着 API“端点”必须了解不同的职责，以“分派(dispatch)”到每个方面的“正确”实现。或者，您允许您的双重职责 API 设计通过让单一事物提供该实现来破坏您的实现。

除此之外:当你有不同的职责时，OK/error 返回码的范围只会变得更加复杂。这只会让“一切”变得更加困难。为您编写测试 - 也为使用您的 API 的客户端。

在您的情况下，用户会:

先使用/api/lead

被告知“未验证”

使用OTP生成API获取验证码

然后使用特定的 OTP API 提交验证码

然后再次使用/api/lead