业务逻辑和RESTful API设计答案

【问题标题】：Business logic and restful API design业务逻辑和RESTful API设计
【发布时间】：2017-01-02 05:32:36
【问题描述】：

假设我们有一个简单的 API，允许客户端获取特定类型的项目列表：

   GET /items/foo
   GET /items/bar
   GET /items/blah

响应是所请求类型的项目列表，每个条目都有一个唯一的 ID。客户端通常会在table/grid/etc中显示这些项目。

现在，我们必须在客户端中实现固定功能，以便另一个 API 允许根据 ID 和类型固定/取消固定项目。所以我正在与我的同事讨论通知客户哪些项目被固定或不固定的可能性。

一个选项是让另一个 API GET /pinning/{type} 返回指定类型的所有固定项目的列表。

另一个解决方案是使用类似的 API GET /pinning/{type} 来返回所有固定项目的 ID 列表。让客户自己解决。

第一个解决方案被接受。他们的论点是后端负责业务逻辑，客户端不应该参与业务逻辑，所以客户端应该只显示它从服务器接收到的数据。这个论点没有卖给我。我认为在这种情况下，服务器应该提供允许客户端执行其他表示逻辑的数据。

哪种解决方案更好？或者还有哪些其他可能的解决方案？

【问题讨论】：

标签： web-services rest restful-architecture restful-url business-logic

【解决方案1】：

如果服务器只返回 GET /pinning/{type} 的 ItemIds，客户端将不得不重复调用 GET /items/{itemId} 之类的东西来获取它可以在 UI 上显示的数据，对吧？这反过来只会增加服务器上的负载。如果 id 就足够了，您可能可以摆脱建议的解决方案。由于客户端和服务器似乎在同一个保护伞下（因为您的公司也是 API 使用者），因此您有足够的信息来做出决定。

即使它是一个有很多客户端的公共 API，我仍然会沿着返回项目的路线而不仅仅是 itemIds - 出于性能原因可能以分页方式。

【讨论】：

是的。通常它需要额外的调用，但在我们的数据固定项目的情况下，在获取特定类型的项目时无论如何都会首先出现。我在想客户做了一个初始的重要提取，所以丢失固定项目的机会非常小。我想我为过早地优化现在可用的数据而感到内疚。我越来越明白为什么第二种解决方案不可取。