我应该在客户端验证 API 响应吗？

Question

假设我有一个使用 RESTFUL API 的应用程序。 例如：我正在向端点发送请求：“/products”并且我正在接收一些 JSON 格式的响应。 然后，我在我的 SPA 应用程序中使用该数据。

一段时间后，响应的形状发生了变化。 我没有被告知这个事实。 结果，我的 SPA 应用程序崩溃了。 更改后，我在应用程序中使用的某些属性在 API 响应中丢失了。 当我验证 SPA 应用程序中的每个响应并在响应中缺少它时放置一些占位符值时，我可以防止这种情况。 但这可能会导致一些性能问题。

无论如何，将 API 响应验证放在客户端是一个好习惯吗？

Answer 1

我认为您遇到的问题与验证无关，但与您的服务器以非向后兼容方式升级有关。 您需要的可能是处理更新的更好方法。

我不认为偶尔下载模式并盲目填充缺失的属性是可行的方法。 您能否构建您的服务以使其具有一些向后兼容性？ 如果您确实必须打破向后兼容性，您是否有充分的理由以及客户端是否有合理的方式来支持它，或者您是否需要更新客户端？

如果您控制服务器和客户端，那么对我有用的策略是：

1. 不要立即进行重大更改。 首先将服务器更新到新版本，然后在以后的更新中停止支持以前的版本。
2. 客户端偶尔可以检查服务器支持哪些版本。 如果他们发现服务器已放弃对客户端使用的版本的支持，请更新客户端。 （也许只是刷新？）

但这是相当广泛的。 不确定这对您有多大帮助，因为它非常依赖于情况。

Answer 2

为了您的描述以及我对 Restful API 的经验，没有关于它的最佳实践，但在某些情况下，API 支持多种自定义内容类型并接受包含版本的标头以处理与不同版本的数据传输对象的向后兼容性.

如果您无权访问您调用的 API，则最好在客户端应用程序上使用空对象模式来查找缺失值以防止崩溃。

Answer 3

您所需要的只是在您的项目中引入 api 版本控制。 因此，您的客户可以依赖某个版本，直到您决定更进一步。 客户端和服务器开发变得更加相互独立。