用于描述 API 响应的接口应该包含所有字段还是只包含应用程序实际需要的字段？答案

【问题标题】：Should interfaces used for describing API responses, contain all fields or only the ones the application actually needs?用于描述 API 响应的接口应该包含所有字段还是只包含应用程序实际需要的字段？
【发布时间】：2020-06-08 12:12:40
【问题描述】：

假设我有一个 API 端点，它返回并带有 20 个字段 的对象。在这 20 个领域中，我只对两个感兴趣。

我的（Typescript）界面（在 FE 方面）应该描述整个对象还是只描述我需要的两个字段？这两种方法是否有任何（有意义的）影响？

想到的一些注意事项：

（完整）开发人员无需直接查看请求即可查看可用的所有内容。
（仅 2 个）开发人员不会被字段的数量及其复杂性所淹没。
（仅 2 个）开发人员只需查看接口即可知道应用程序中正在使用哪些字段。

一个子问题：责任应该在 BE 一方吗？ API 是否应该只返回 FE 实际需要的东西？（让我们假设 GraphQL 和其他让 FE 创建查询的服务不可用）。每当 FE 需要什么时，这是否会给 BE 团队带来不必要的工作？

我很乐意回答这两个问题！

谢谢！

【问题讨论】：

经验法则是只问你需要什么。我认为这里没有理由期待您不使用的东西。开发人员应该知道阅读文档或查看响应，以防 FE 中有新功能或修改。

标签： typescript interface frontend api-design

【解决方案1】：

一般来说，API 应该只返回与 FE 本身相关的字段。如果存在对 FE 很重要但有时可能未定义的字段，则仍应将其作为 null 值返回给 FE，因为即使是 null，FE 至少应该知道该字段有时需要吗？

如果您的 API 对象包含 20 个字段，那么您的接口也应该包含 20 个字段，您可以将 API 响应映射到仅包含您的 FE 所需字段的接口，但这是

a) 容易出错，因为您基本上必须映射到可能存在或不存在的属性，因为您一开始无法知道 API 响应是什么样的，并且

b) 它会创建不必要的代码和 API 在返回响应之前应该为您完成的工作。

Imo，最好知道字段在那里，而不是映射响应并基本上忽略 API 响应的一部分。您的模型和接口应始终位于单独的文件中，尤其是在这种情况下，记录它们的用途（例如，在属性上方的注释中）。

【讨论】：