REST API:单个 API 是否应该承担多项职责? [英] REST API: Should single API have multiple responsibilities?

查看:15
本文介绍了REST API:单个 API 是否应该承担多项职责?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

We have classified goods website where we do not have login but users can view products listed by other users. To view details of other users, they have to provide their contact details. To verify if user has provided the correct mobile number, we send back OTP code to the number. The API flow looks like:

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

POST/api/lead/

POST /api/lead/

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

如果移动"的 API 响应已验证(响应代码:200):

Response of API if "mobile" is already verified (Response code: 200):

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

如果移动"的响应尚未验证(响应代码:403):

Response if "mobile" is NOT already verified (Response code: 403):

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

  1. 用户通过移动设备接收到的 OTP 再次向同一个潜在客户 API 发回请求:

请求有效载荷:

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

如果 OTP 正确,它会发回卖家详细信息作为响应.如果 OTP提供的不正确,回复是:

It sends back seller details in response if OTP is correct. If OTP provided is not correct, the response is:

{
  "Incorrect OTP."
}

我在这个 API 设计中发现了一些问题:

I see few issues in this API design:

  1. 此 API 做了大量工作,即返回卖家详细信息、返回 OTP、验证 OTP 等.我们可以轻松地将 OTP 相关功能分解为其他一些 API.例如,一个用于生成 OTP 的 API,即 GET/api/otp/,另一个用于验证 OTP 的 API,即 POST api/verifyotp/.这将增加来自客户端的 API 调用次数,即第一个客户端将启动 POST Lead API,如果未验证数量,则客户端将命中 OTP API.要通过 OTP 进行验证,它将调用 verifyOTP api.如果通过验证,它将调用 Lead API 以获取卖家详细信息.因此,基本上它进行了 4 个 API 调用,而在上述方法中则是 2 个 API 调用.
  2. 这与 HATEOS 不兼容,HATEOS 建议REST 客户端通过简单的固定 URL 进入 REST 应用程序.客户端可能采取的所有未来操作都在从服务器返回的资源表示中发现."

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

Can someone suggest which approach is better?

推荐答案

简单的答案:.

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

It is called single responsibility principle for a reason.

允许在您的公共 API 中承担多个职责意味着 API端点"必须了解不同的职责,以便分派"这些方面中的每一个的正确"实现.或者您允许您的双重职责 API 设计通过提供该实现的单一事物破坏您的实现.

Allowing for more than one responsibility in the your public API means that the API "endpoint" has to understand the different responsibilities to "dispatch" to the "correct" implementation for each of these aspects. Or you allow your dual-responsibility API design to corrupt your implementation by having a single thing providing that implementation.

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

And beyond that: when you have different responsibilities, the range of OK/error return codes simply turns more complicated. That simply makes "everything" harder. For you to write tests - but also for the clients using your API.

在您的情况下,用户会:

In your case, the user does:

  • 先使用/api/lead
  • 被告知未验证"
  • 使用OTP生成API获取验证码
  • 然后使用特定的 OTP API 提交验证码
  • 然后再次使用/api/lead

这篇关于REST API:单个 API 是否应该承担多项职责?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆