1

FooBar Api 已发布

假设有一个开发人员团队正在开发一个 API，称为FooBar api具有几个端点：

GET /foo
    # returns {'bar': '/bar', 'data': 'foo'}

GET /bar
    # returns {'data': 'hello world!'}

现在，让我们说FooBar api爆炸并变得非常流行。来自世界各地的开发人员都在使用它FooBar api，现在成千上万的项目完全依赖它。

问题

最近FooBar api有一个新的项目经理。他说，现在希望响应返回 amessage而不是data，因为message“更具描述性”。不幸的是，对 API 的任何更改FooBar都可能破坏数以千计的此类项目。尽管所有这些项目被破坏的开发人员大多会耐心并理解变化，但FooBar团队不想破坏他们自己的依赖项目并决定最好保持 api 向后兼容。

解决方案

FooBar api需要进行版本控制。不幸的是，没有好的方法可以做到这一点。对团队来说幸运的是FooBar，他们的项目经理最了解并决定应该通过在 url 中放置版本号来完成版本控制，因为“这是他可以看到的部分”。因此，一旦第二个版本FooBar api完成，这两个版本应该如下所示：

FooBar v1
GET /foo
    # returns {'bar': '/bar', 'data': 'foo'}

GET /bar
    # returns {'data': 'hello world!'}

FooBar v2
GET /v2/foo
    # returns {'bar': '<url to bar>', 'message': 'foo'}

GET /v2/bar
    # returns {'message': 'hello world!'}

第二个问题

FooBar团队现在有另一个问题；他们不知道应该输入什么<url to bar>。在几乎无限可能的字符排列中，他们令人印象深刻地能够将其归结为两个选择 -/v2/bar和/bar。

问题

/v2/bar使用vs的优缺点是/bar什么？

4

1 回答 1

4

都不做。具有不同 URL 的同一资源的两种不同表示形式与 REST 或 HTTP 不一致。它们是相同的资源，它们应该具有相同的 URL。

无论客户端使用 API 的版本 1 还是 API 的版本 2，他们仍然指的是同一个资源，他们只是想要它的不同表示。所以完全摆脱/v2/你的 URL，让你的客户要求他们想要的版本作为媒体类型参数：

GET /foo HTTP/1.1
Accept: application/vnd.whatever+json;version=2
Connection: close

您现有的客户端不会提供版本参数，您可以默认使用版本 1。支持 API 版本 2 的较新客户端将知道请求该资源的版本 2 表示。无论客户端使用哪个版本的 API，您的链接都可以正确引用相同的资源。

于 2016-07-25T22:35:40.260 回答