REST API:单个API应该承担多重责任吗？

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"
}

如果"移动"尚未验证,则回复(响应代码: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.例如,一个用于生成OTP的API,即GET/api/otp /,其他用于验证OTP的API,即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的客户编写测试.

在您的情况下,用户执行以下操作: