如何设计可扩展的静态/非静态API？

Question

我有一个API“ x”，它今天对4个参数-a，b，c，d进行了CRUD。 明天如果由于需求的变化，如果我必须在同一API中支持更多的参数，那么最好的处理方法是什么？

我是否应该继续使用引入的新参数更新数据库，并在需求发生变化时继续执行此操作？

我的一位同伴建议API应该接受一个JSON对象，该对象可以接受任何一组参数和任何一组键值对。 每次通过此JSON获得一组新的键值对时，都会使用该值更新我的params表，然后需求可以随时随地更改。

我认为这很难在客户端之间维护，因为API实际上会接受任何键值对，因此一个平台可能会辩论以一种格式发送这些键值对，而另一种平台则愿意以另一种格式发送。格式。 另外，将很难进行验证并检查可选和强制参数。

任何线索表示赞赏

Answer 1

我的回答有些细微差别，所以要当心。

我发现在实践中，我们不会对API进行太多更改，而当我们这样做时，我们通常可以采用向后兼容的方式来进行更改。 这确实意味着我们添加了可选字段。

如果您控制所有客户端，这也相当容易，因为您可以升级所有客户端，因此这并不是真正的问题。

当您进行更多更改或仅添加一些属性而做的事情时，这将变得更加困难，并且这是与您联系的第三方，您可以轻松地对其进行升级。

有多种解决方法，但是我的建议是遵循github的模型。

对于较大的重大更改，它们将更改Content-Type标头。 当前，github请求的Content-Type为：

Accept: application/vnd.github.v3+json

在他们进行重大突破之前，它是：

Accept: application/vnd.github.v2+json

对于易于更改的实验性API，可以使用实验性Content-Type ：

Accept: application/vnd.github.mister-fantastic-preview+json

通常，此想法可用于宁静的设计，但不是唯一的解决方案。