REST API 更新设计
REST API Update Design
我看过很多关于 REST 及其设计实现的文章 API。然而，我有几个问题，也许他们只是固执己见，因为没有 "one fits all solution" REST 或 API 开发一般。
请注意，这些问题与联系和接收来自 SDK 的请求有关。
我的问题都与 URI 形式有关，我相信它是这样称呼的。我已经看到它以几种方式表示，但我最关心的是版本控制和 "dynamic" 部分。
对于我的第一个问题（版本化），我看到经常使用以下方法。
/customers/accounts/V3.4/customer_id/1234
/customers/accounts/V3.5/customer_id/1234
开发人员将通过保留通用版本 class 来实现这一点，并且当他们进行调用时，它会获取开发人员设置的任何版本。因此，如果他们想升级到新的 API 版本，他们只需在一个位置修改 V#.#。我想知道这个想法在实践中有多好，特别是对于 SDK。我的一般想法是，这没问题。我相信这是因为清楚地指出了版本。如果需要进行更改，只需更新您的版本调用即可。考虑到 SDK，使用旧的 API 不会破坏任何东西，就好像它们暂时不更新一样，那么它们的 API 请求仍然可以，但会通过旧端点路由。
问题 1. 使用上述方法进行版本控制是否适合 API 更新？亲's/Cons?
第二个关于动态值的问题可以看如下
/customers/V4.3/{customer_id}/account
versus
/customers/accounts/V3.4/customer_id/1234
我不确定拥有动态端点与如上所述对它们进行硬编码是否有更好的权衡。我这样说是因为如果我们有一个场景，我们希望将详细信息添加到 "account" 页面怎么办。
在上面的示例中 customers/V4.3 不必更新，因为它仍然包含相同的用户列表中点。我们将能够在不导致版本更改的情况下更新帐户 API。 （如果这是一个糟糕的主意，请原谅我）。但是对于第二个选项，我们将不得不更新版本控制，因为这是一个中点
问题 2.在上面的示例中，关注更多静态端点还是动态端点更好？
对这方面的了解还很陌生，如果我对 API 设计做出了一些错误的假设或结论，请原谅我。
使用参数有什么问题？
恕我直言
动态的或将来可能发生变化的事物永远不应成为 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 用户选择版本和执行操作之前，我会认真考虑要求。
也请看看
这是RESTful debates可以原地踏步的其中之一。您可以通过三个选项来指定版本：URL、内容类型或自定义 header。所有这些都会被一些人认为 "wrong"。
特洛伊·亨特 (Troy Hunt) 在此处就优缺点进行了很好的讨论：
http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html
但是，我不一定会很快找到版本控制作为解决方案。您可能希望通过使用更宽容的消费者、投资更多 up-front 设计或将 open/closed principle 应用于您的 API 来考虑 side-stepping 这个问题。
这里更详细地表达了这个论点：
http://martinfowler.com/articles/enterpriseREST.html#versioning
其中包含一段精彩的引述：
"Some people, when confronted with a problem, think "I know, I'll use versioning." Now they have 2.1.0 problems."
我看过很多关于 REST 及其设计实现的文章 API。然而，我有几个问题，也许他们只是固执己见，因为没有 "one fits all solution" REST 或 API 开发一般。
请注意，这些问题与联系和接收来自 SDK 的请求有关。
我的问题都与 URI 形式有关，我相信它是这样称呼的。我已经看到它以几种方式表示，但我最关心的是版本控制和 "dynamic" 部分。
对于我的第一个问题（版本化），我看到经常使用以下方法。
/customers/accounts/V3.4/customer_id/1234
/customers/accounts/V3.5/customer_id/1234
开发人员将通过保留通用版本 class 来实现这一点，并且当他们进行调用时，它会获取开发人员设置的任何版本。因此，如果他们想升级到新的 API 版本，他们只需在一个位置修改 V#.#。我想知道这个想法在实践中有多好，特别是对于 SDK。我的一般想法是，这没问题。我相信这是因为清楚地指出了版本。如果需要进行更改，只需更新您的版本调用即可。考虑到 SDK，使用旧的 API 不会破坏任何东西，就好像它们暂时不更新一样，那么它们的 API 请求仍然可以，但会通过旧端点路由。
问题 1. 使用上述方法进行版本控制是否适合 API 更新？亲's/Cons?
第二个关于动态值的问题可以看如下
/customers/V4.3/{customer_id}/account
versus
/customers/accounts/V3.4/customer_id/1234
我不确定拥有动态端点与如上所述对它们进行硬编码是否有更好的权衡。我这样说是因为如果我们有一个场景，我们希望将详细信息添加到 "account" 页面怎么办。
在上面的示例中 customers/V4.3 不必更新，因为它仍然包含相同的用户列表中点。我们将能够在不导致版本更改的情况下更新帐户 API。 （如果这是一个糟糕的主意，请原谅我）。但是对于第二个选项，我们将不得不更新版本控制，因为这是一个中点
问题 2.在上面的示例中，关注更多静态端点还是动态端点更好？
对这方面的了解还很陌生，如果我对 API 设计做出了一些错误的假设或结论，请原谅我。
使用参数有什么问题？
恕我直言
动态的或将来可能发生变化的事物永远不应成为 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 用户选择版本和执行操作之前，我会认真考虑要求。
也请看看
这是RESTful debates可以原地踏步的其中之一。您可以通过三个选项来指定版本：URL、内容类型或自定义 header。所有这些都会被一些人认为 "wrong"。
特洛伊·亨特 (Troy Hunt) 在此处就优缺点进行了很好的讨论：
http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html
但是，我不一定会很快找到版本控制作为解决方案。您可能希望通过使用更宽容的消费者、投资更多 up-front 设计或将 open/closed principle 应用于您的 API 来考虑 side-stepping 这个问题。
这里更详细地表达了这个论点：
http://martinfowler.com/articles/enterpriseREST.html#versioning
其中包含一段精彩的引述：
"Some people, when confronted with a problem, think "I know, I'll use versioning." Now they have 2.1.0 problems."