Android Google应用程序引擎版本URL和应用程序版本控制

当您将新版本上载到app engine时，我们称之为“10”，您可以使用以下url直接向该版本发送请求：

我发现它非常有用，并且我养成了一个习惯，即发布指向相应服务器版本的android应用程序。因此，当我将版本10上传到它指向的play store时，版本9也是如此

这是正确的用法还是此功能？应用程序引擎版本控制的最佳实践是什么？

我这样做是因为我想保持向后兼容性，这样，如果我在服务器中进行更改，旧客户端不会注意到，因为它们连接到旧版本

---

我理解这是有问题的，因为所有版本都共享相同的DB，并且当我为不适用于其他版本的默认版本配置预热时可能会出现问题那么我这样使用它是不是犯了错误？

应用程序版本在部署新版本之前非常有用。我不会使用它来确保与现有客户端的向后兼容性。此外，每个应用程序只能有有限的版本数

每个应用程序最多可以有十个版本；一旦达到该限制，就需要先删除现有版本，然后才能部署新版本

另一个要考虑的是，一些AppEngine服务（例如数据存储）在特定版本上是独立的，但是其他（例如CRON作业）对具体版本（通常是默认版本，除非另有说明）是紧密的。 但是，您可以有不同版本的应用程序公共接口（REST/SOAP服务或您使用的任何服务），因此新功能或更改仅对相应的客户端可用

下面是一个使用版本的虚拟RESTAPI示例

https://myapp.com/api/v1/questions/10/answers?max=10

https://myapp.com/api/v2/questions/10/latest-10-answers

---

除此之外，这可能会稍微贵一些，因为我认为每个服务版本都需要一个实例集，而不是所有请求共享所有实例。是的，你是对的。但这比我升级服务器时用户可能遇到的错误要少，因为他仍然有一个旧版本的应用程序。这是个好主意。十个版本并没有困扰我，因为我相信用户会更新应用程序，但是，如果有人真的不想更新或无法更新，这是一个很好的观点。还有其他的想法，为什么你认为这是一个糟糕的做法？我增加了另一件事要考虑。是的，这是一个很好的考虑，但我可以指定一个特定版本的Con工作，所以解决了这个问题。我在android和java服务器之间使用一个共享库，并且我有一个版本常量，所以我可以将它传递给cron作业（虽然我从未使用过cron作业，所以我不确定）。我非常喜欢API版本控制，我想我可能会适应它。不管怎样，如果它帮助你解决了你的问题，那么把答案标记为已接受，这样其他人就可以从中受益。