我正在构建一个 API，但我有一个关于如何表示对象的问题。
想象一下，我们有一个系统，其中包含具有大量属性的文章。其中一些属性很复杂，例如文章的作者指的是另一个对象。我们有一个获取系统中所有文章的 URL，还有一个获取特定文章的 URL。
我的第一个实现方法是创建同一个对象 Article 的两个表示，因为当您请求所有文章时，您不会检索有关文章的所有信息，而是仅检索标题、日期和作者姓名（而不是整个 Author 对象），不包括标签或内容等其他属性。这背后的想法是尝试使所有文章的响应更轻松。
现在我要去客户端，例如，我决定为 Android 实现一个 SDK。所以第一步是创建对象来存储我从 API 检索到的信息。现在出现了一个问题，因为我想定义 Article 对象，但我需要它的两个版本，它不仅更难实现，而且更难使用。
所以我的问题是，在定义 API 时，拥有同一个对象的多个版本（可能是轻量版和完整版）以在发送请求结果但生成更困难的结果时节省一些带宽是一种好习惯吗？使用服务，还是不值得，您应该始终检索相同版本的对象，产生更重的响应但使服务更易于使用？
我在一家也处理文章的公司工作，我们也有一个 REST API 来公开数据。
我认为你在正确的轨道上，但我什至会更进一步。这些是 API 中对大型实体的潜在三个调用：
索引。对于文章，这类似于 /articles。它只返回文章 ID 列表。您可以添加参数来过滤、排序等。它非常轻量级，我发现它非常有用。
标题/迷你/轻型版本。这些只是您认为可以满足最广泛用例的关键领域。对我们来说，我们有很多用例，我们可能希望显示前 5 篇文章，在这些情况下，只有标题、作者，可能还有出版日期。这些字段属于“标题”文章或“轻”文章。这对于 AJAX 调用特别有用，因为您不想返回整篇文章（对我们来说，对象非常大。）
完整版。这是完整的文章。所有文本/段落/图像参考 - 一切。这是一个沉重的电话，但你将保证得到任何可用的东西。
然后只需要纪律就可以让物体保持原样。理想情况下，用户能够获得 (2) 中描述的版本以通过网络节省时间，但如果必须，他们会选择 (3)。
我考虑过一种动态的方式来只返回人们感兴趣的字段，但这将是很多实现。基本上，这个想法是让用户转到 /article，然后向他们展示一个示例 JSON 结果。然后用户可以点击他们想要返回的字段并获得一个令牌。然后他们将令牌作为参数传递给 API，然后 API 就会知道要返回哪些字段。
创建动态架构。很多工作，我从来没有解决它，但你可以看到，如果你想有创意，你可以。
考虑您的数据（对于一个 API 客户端）是否发生了很大变化。如果可以在客户端缓存数据，那将通过减少与 API 的联系来提高性能。否则，我认为拥有轻量级和全尺寸对象类型（或者更像是同一对象类型的两个视图）是个好主意。
在客户端中，您应该将其实现为具有所有属性的一种对象类型（以使其保持干燥；不要重复自己）。获取轻量级对象时，您只存储一些属性，其余为 null（或给定属性类型的类似“未定义”值）。应该可以确定是否加载了所有属性子集或仅加载了部分属性子集。
在给定模型（即作者）的客户端中发出 API 请求时，您应该明确说明是否需要轻量级或全尺寸对象以及缓存数据是否可接受。这使得控制 UI 层中的数据成为可能。例如，作者列表可能只需要显示姓名和与该作者相关的文章数量。显示作者屏幕时，需要更多属性。此外，如果使用缓存数据，您应该为用户提供一种刷新它的方法。
当应用程序工作时，您可以开始实施优化，例如：如果已经知道完整的 scala 数据，则不要获取轻量级数据；如果存在最近的缓存副本，则根本不要获取数据。我认为最好的还是看实际用例，以对用户最高的价值来提升性能。