业务逻辑和宁静的API设计

Question

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

absolute

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

现在在客户端我们必须实现固定功能，以便另一个API允许根据他们的ID和＆amp ;;固定/取消固定项目。他们的类型。因此，我正与同事讨论可能告知客户哪些项目是固定的。

一个选项是让另一个API GET /items/foo GET /items/bar GET /items/blah 返回指定类型的所有固定项的列表。

另一种解决方案是使用类似的API GET /pinning/{type}来返回所有固定项的ID列表。让客户对其进行排序。

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

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

Answer 1

如果服务器只返回GET /pinning/{type}的ItemIds，则客户端必须重复调用类似GET /items/{itemId}的内容才能获取可在UI上显示的数据，对吗？这反过来只会增加服务器上的负载。如果id足够，你可以放弃提出的解决方案。由于客户端和服务器似乎都在同一个保护伞下（因为您的公司也是API消费者），因此您有足够的信息来做出决定。

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