Question

我查看了很多关于REST及其API设计实现的文章。然而，我有几个问题，也许他们只是自以为是，因为没有＆＃34;一个适合所有解决方案＆＃34;通常用于REST或API开发。

请注意，这些问题与来自SDK的联系和接收请求有关。

我的问题都与URI形式有关，因为我认为它被称为。我已经看到过这方面的几个方面，但我最关心的是版本控制和动态＆＃34;部分。

对于我的第一个问题（版本＆＃39; ing），我看到经常使用以下方法。

/customers/accounts/V3.4/customer_id/1234
/customers/accounts/V3.5/customer_id/1234

开发人员会通过保留一般版本类来实现这一点，并且当他们进行调用时，它会抓住开发人员设置的任何版本。因此，如果他们想要升级到新的API版本，他们只需要在一个位置修改V＃。＃。我想知道这个想法在实践中有多好，特别是对于SDK。我的一般想法是，这没关系。我相信这是明确指出的版本。如果需要进行更改，只需更新您的版本的电话即可。考虑到SDK，使用旧的API不会破坏任何内容，就好像它们暂时不会更新一样，那么它们的API请求仍然会正常，但会路由到较旧的端点。

问题1。版本使用上述方法是否可以用于API更新？亲＆＃39; S /缺点

关于动态值的第二个问题可以看作如下。

/customers/V4.3/{customer_id}/account
versus
/customers/accounts/V3.4/customer_id/1234

我不确定是否有更好的权衡来获得动态端点与上面列出的硬编码。我这样说是因为如果我们有一个场景，我们希望在＆＃34;帐户＆＃34;页。

在上面的例子中， customers / V4.3 不需要更新，因为它仍然包含相同的用户列表中点。我们将能够在不导致版本更改的情况下更新帐户API。（如果这是一个可怕的想法，请原谅我）。但是使用第二个选项，我们必须更新版本，因为它是一个中点

问题2。在上面的示例中，是否更关注更多静态或动态端点？

如果我对API设计做出一些错误的假设或结论，请原谅我。

Answer 1

使用参数有什么问题？

IMHO

动态或未来可能发生变化的事情永远不应成为URL路径的一部分。

这就是参数存在的原因。好处是： -

http://example.com/api/resource/?customer_id=1234&v=3.4

您的脚本将对其进行相同的处理： -

http://example.com/api/resource/?v=3.4&customer_id=1234

我不知道SDK的上下文，但在允许API用户选择版本和版本之前，我会认真考虑要求。执行行动。

另请查看https://stackoverflow.com/a/17999251/2489860

Answer 2

这是RESTful debates中的其中一个可以围成圈子的。您有三个用于指定版本的选项：URL，内容类型或自定义标头。一些人认为所有这些都是“错误的”。

Troy Hunt在这里围绕利弊撰写了一篇非常好的讨论：

http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html

但是，作为一种解决方案，我不一定非常快速地进行版本控制。您可能需要考虑通过使用更宽容的消费者，投资更多的前期设计或将open/closed principle应用于您的API来解决问题。

这个论点在这里有更详细的表达：

http://martinfowler.com/articles/enterpriseREST.html#versioning

它包括一个很好的引用：

“有些人在遇到问题时会想”我知道，我会使用版本控制。“现在他们有2.1.0问题。”

REST API更新设计

2 个答案: