问题

Question

FooBar Api已发布

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

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

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

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

问题

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

解决方案

FooBar api需要进行版本控制。不幸的是there is no good way to do this。幸运的是，对于FooBar团队，他们的项目经理最了解并决定版本控制应该通过在网址中放置一个版本号来完成，因为“这是他能看到的部分”。因此，一旦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？

的优点和缺点是什么？

Answer 1

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

无论客户端使用API的版本1还是API的版本2，它们仍然指向相同的资源，他们只是想要不同的表示。因此，请完全删除您的网址中的/v2/，并让您的客户要求他们想要的版本作为媒体类型参数：

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

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

Flask Rest API版本控制 - 返回的URL

FooBar Api已发布

问题

解决方案

第二个问题

问题

1 个答案: