通常应该为REST服务开发一个客户端库来帮助防止API损坏吗？

我们有一个项目，将由同一团队开发UI代码，但使用与服务层（REST / Java）不同的语言（Python / Django）。每个层的代码存在于不同的代码存储库中，并且可以遵循不同的发布周期。我正在尝试提出一个过程，该过程将从UI层的角度防止/减少服务层中的更改。

我曾经考虑过在UI层级别编写集成测试，每当我们构建UI或服务层时（我们使用Jenkins作为我们的CI工具来构建两个Git仓库中的代码）时，我们都会运行集成测试。发生故障，则服务层中的某些内容中断，并且提交不被接受。

让服务层的开发人员为UI层中存在的REST服务创建并维护一个客户端库是否也是一个好主意（这是最佳实践吗？），只要REST中有重大更改，它们就会更新。他们的服务API？可以想象，我们将拥有UI代码所针对的静态类型的API的优势。如果客户端库API发生更改，则UI代码将无法编译（因此我们将尽快知道有重大更改）。我还将在构建UI或服务层时运行集成测试，以进一步验证UI和服务之间的集成是否仍然有效。

通常，对于即将淘汰的API方法，请选择一个约定并“弃用”它们，尤其是在完整的替代API可用并经过测试之后。保留旧的API（基本上），但标记方法签名元数据或插入日志记录事件，以便可以清楚地识别用法。

在服务API中进行日志记录是一回事，而警告正在使用的客户端则是另一回事。对于REST，我认为没有可靠的标准做法。即使调用的方法成功，FourSquare API客户端也可以发现不推荐使用的方法（HTTP 200代码，但是errorType将设置为“不推荐使用”）。可能是一种合理的策略，可以为消耗客户提供了解API中不推荐使用的方法的机会，而又不会造成损坏。

https://developer.foursquare.com/overview/responses

在您的API指南中，建议一个日期或内部版本号，其中已弃用的API将被完全删除。当您充实您的弃用策略时，您将要向API的使用者警告所建议的策略是什么（他们如何发现不赞成使用的方法，如何过渡到替换API，以及何时不再允许不赞成使用的API，如果在API清除期间清除），并征求他们的反馈，以确保该过程对每个人都是有益的。

对API进行版本控制是另一种可能。部署新版本时，也请保持旧版本处于活动状态，并允许通过请求进行协商。如果您维护最新的2或3版本，则UI代码可以按照自己的进度进行升级。

一次至少有三个问题，让我们一一解答

• “拥有一个用于REST服务的客户端库是一个好主意吗？”

很可能是这样，只要您不希望任意REST调用直接散布在所有UI代码中。

• “让服务层的开发人员创建并维护lib是个好主意吗？”

这取决于您团队中的人。API的维护者应该知道服务层中可用的内容以及UI层的要求。因此，它既可以是来自服务层的人员，也可以是UI层的人员，或者（取决于规模和其他任务）是独立于两个团队的人员。

• [我们将从以下事实中受益：]“如果客户端库API发生更改，则UI代码将无法编译”

您不是说UI用Python编写吗？这不是静态类型的语言，因此我不希望API更改会立即导致构建中断。我认为这时我错了，这里有一个静态类型的API-只要在向API 添加一些新功能（例如新的可选参数）时构建不会中断，您就可以在这里获得一些好处。否则，您会给团队带来不必要的开销。