RESTful 设计，用于访问来自不同受众的不同格式的相同资源答案

【问题标题】：RESTful design for accessing the same resource in different formats from different audiencesRESTful 设计，用于访问来自不同受众的不同格式的相同资源
【发布时间】：2020-02-03 22:44:30
【问题描述】：

用例

我正在建立一个网上商店，人们可以在其中注册/登录并购买（然后管理）他们的 SaaS 许可证。为此，我（除其他外）创建了以下 REST 端点：

// Lists all licenses which are linked to this user
r.Get("/users/{userID}/licenses", api.LicenseSvc.HandleGetLicenses())

// List details (such as purchase date, seat information, ...) for a given licenseID
r.Get("/users/{userID}/licenses/{licenseID}", api.LicenseSvc.HandleGetLicense())

// Creates a new license for the signed in user
r.Post("/users/{userID}/licenses", api.LicenseSvc.HandleCreateLicense())

// Each license has a limited number of seats. The license manager can free up seats to make room for others
r.Delete("/users/{userID}/licenses/{licenseID}/seats/{seatID}", api.LicenseSvc.HandleDeleteSeat())

上述端点只应在网上商店/许可证管理面板中使用。同时，相同的服务必须为实际使用用户之前创建/购买的许可证的 SaaS 产品提供端点。此 SaaS 产品需要不同的端点，例如：

在启动时检查给定许可证是否有效的端点
同样通过 ID 获取许可证的端点（见上文），但它应该只返回许可证资源的子集（例如，它不应该返回购买许可证的日期）

我的问题

由于我正在构建一个 REST API，该 API 由两个不同的“受众”（一方面是许可证管理器/客户，另一方面是 SaaS 软件）使用，我觉得我遇到了冲突.

两个受众的身份验证不同，两个受众都希望访问同一种资源（例如许可证），但资源“格式”（SaaS 请求者没有客户敏感数据）应该因受众而异。

这应该通过不同的 REST URL 反映出来，还是应该在我的路由处理程序中处理所有这些逻辑？
我是否应该创建两个不同的服务来服务这些不同的受众？就像一个用于用户面板/许可证管理的 API 和一个用于 SaaS 产品的 API！？

【问题讨论】：

讨厌成为那个人，但你考虑过使用 GraphQL 吗？您正在准确描述它的创建原因（几乎）...
说实话不是。我知道 GraphQL 解决了过度获取问题，但我还没有深入研究授权。我会阅读它，看看它是否对我有意义。无论结果如何，我都很乐意弄清楚如何以 RESTful 方式解决它。
公平。老实说，我发现这个问题有点宽泛和基于 SO 的观点，但我不会这样标记它。我也不知道您使用的是什么语言/框架，因此不知道您的能力。话虽如此，我个人的看法是，提供额外的服务是一种矫枉过正。服务很复杂，应该尽量减少这个表面。你当然应该有两个不同的终点，因为这对读者来说更清楚。如果我在 FP 中，我会获取相同的模式并让隐式转换器删除控制器上的敏感内容。
我想你可以在路由中指定受众——这样你的问题可能会消失，但是你会暴露两个不同的 API 端点，我认为这是有道理的，因为它们指向两个不同的需要通过两个不同地址引入的资源
我仍然相信大多数人不了解 REST 是什么，什么不是，这在一个专门为软件开发人员和工程师服务的平台上尤其令人沮丧。与其尝试真正实现一个符合菲尔丁论文的系统，其目标是实现客户端与服务器的强解耦，所有人似乎都遵循这种伪 REST-but-true-WebRPC 的事情，并相信他们正在做正确的事事物。如果 Web 可以像“我们的”现代 Web 应用程序一样工作，我们需要为每个我们请求的主页配备一个新浏览器，因为这确实是所有使用他们的 REST API 所做的事情

标签： rest

【解决方案1】：

REST 没有为这些多客户端场景做好充分准备。我见过许多 REST api，其中资源的某些属性只有在我觉得完全没问题的某些情况下才会被填充。但是，我也看到了许多将多个用例组合成单一资源模型的示例，其中具有限制结构的 swagger 文档严重无法传达每个字段的目的。

所以：只要用例差异不大，我会尽量减少端点数量。

提示：看看 GraphQL，它可以更好地处理这种情况，只查询某些集合，甚至只查询某些字段，让客户端控制。然而，使用 GraphQL 作为主要接口仍然有些奇特，与可用的大量 REST 基础设施相比，初始成本相当可观。还是值得的。

【讨论】：