API 是不是应该在 API 响应中发回 UI 层文本/数据以允许在旧的 android/ios 应用程序版本中随时更改？

Posted 2023-05-07

【中文标题】API 是不是应该在 API 响应中发回 UI 层文本/数据以允许在旧的 android/ios 应用程序版本中随时更改？

【英文标题】：Should APIs send back UI layer text/data in API response to allow changes anytime in older android/ios app versions?API 是否应该在 API 响应中发回 UI 层文本/数据以允许在旧的 android/ios 应用程序版本中随时更改？

【发布时间】：2017-12-23 18:24:56

【问题描述】：

（各种 android/ios 屏幕的标题、各种表单控件的标签）应该在 android/ios 应用程序中硬编码还是应该从 API 响应中获取此类数据？

大部分页面/页面部分都有标题。在带有文本框/组合框的表单中，我们也为每个控件提供了标签。此类 UI 信息是否应该被硬编码或从 API 中获取？

这里有几个问题：

在 android/ios 应用程序上进行所有这些硬编码的优点：干净且轻量级的 API 数据。 API 将仅包含数据部分，而不包含标题、标签等用户界面元素。这将节省带宽并使 API 更快。 在 android/ios 应用程序上硬编码的缺点：如果我们以后想更改这些标题、标签，我们只能在较新的版本上这样做。所有以前的应用程序版本将继续仅显示旧标题/标签。如果我们从 API 中获取这些数据，我们可以随时在所有版本中更改这些数据。

哪种方法是正确的？或者我们是否应该根据标题/标签将来是否可以更改并且需要为所有应用程序版本更改它们的事实来决定这一点，如果是这种情况，那么它应该在 API 中，否则它们可能会被硬编码？ 应用程序是否可以使用 firebase 获取此类信息并在以前的应用程序版本中进行更改？

【问题讨论】：

Should Web API response just contain the data OR data with User Interface things for future flexibility on android and ios clients?的可能重复

【参考方案1】：

如果没有至少一些硬编码的默认设置允许用户在应用程序中初始导航而无需等待 API 调用检索，就从 API 调用填充所有 UI 元素可能不是一个很好的用户体验信息。此外，如果您尝试使用这种服务器端 UI 设计创建应用程序，您可能希望主要使用 Web 组件，甚至可能将 html 提供给应用程序，因为内容之间可能存在不匹配（即标签的文本、按钮和文本字段）和 UI 元素本身。例如，假设一个分段控件最初设计为仅容纳两个选项（“家庭”和“工作”），然后在列表中添加了一个附加文本选项（“家庭”、“工作”和“健身房”） .