【问题标题】:Fine grained vs coarse grained REST API细粒度与粗粒度 REST API
【发布时间】:2016-05-23 18:23:25
【问题描述】:

我正在开发一个用于管理用户的 REST API。每个用户都有一个姓名和一个他自己的联系人列表(姓名、类型、值)。我正在考虑两种建模 REST API 的方法,即粗粒度方法:

  • GET /user/{id},获取用户详细信息及其联系人
  • POST /users,添加新用户及其联系人
  • PUT /users/{id},更新用户及其联系人

或细粒度的方法:

  • GET /user/{id},获取用户详细信息
  • GET /user/{id}/contacts,获取用户的联系人
  • POST /user,添加新用户
  • PUT /user/{id},更新用户
  • POST /user/{id}/contacts,添加新的用户联系人
  • PUT /user/{id}/contact/{id},更新用户联系人
  • DELETE /user/{id}/contact/{id},删除用户联系人

何时应该选择细粒度方法而不是粗粒度方法?

【问题讨论】:

  • 为什么不能同时使用? post/put 只是添加/更新用户及其联系人,但您也可以根据需要单独编辑联系人?
  • 更多请看这个问题:Coarse grained vs Fine grained

标签: rest architecture


【解决方案1】:

这个决定取决于您的 API 将如何被使用。如果此 API 的主要功能是跟踪用户的联系人,那么我认为采用细粒度方法是有意义的。

作为 API 的使用者,细粒度方法具有与粗粒度方法相同的功能,但还添加了更具体的端点。这样想,作为后端的开发人员,您知道联系人嵌套在用户对象中,但 API 的使用者不知道这一点,他们也不需要知道这一点。他们只知道用户与其联系人之间存在某种关系。

此外,细粒度的方法将使您的后端代码井井有条。您将为 API 提供的每个端点提供特定的方法,因此代码将更易于阅读和理解。您还可以进行更细粒度和更清晰的错误处理。

【讨论】:

  • 细粒度方法保持后端代码干净的说法的来源是什么?您是否假设使用了关系数据库(未基于文档),其中细粒度方法中的每个 API 调用都是对一个数据库表的一次 SQL 更新(插入/更新/删除)?
  • 是的,假设这些请求中的每一个都对应一个特定的数据库操作,我认为当方法更细粒度时更容易组织代码并保持干净。然后,您可以将每个请求映射到后端的特定方法,代码非常容易理解。
猜你喜欢
  • 1970-01-01
  • 2014-11-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-04-24
  • 1970-01-01
  • 2012-02-20
  • 2018-01-16
相关资源
最近更新 更多