RESTful API版本控制

我是RESTful API的新手，目前正在开发我的第一个API，以便后续的移动应用程序。我有一个关于API版本以及如何管理/处理它们的问题

此时，我的API“version”是一个名为v的目录，我的API类驻留在该目录中。在该目录中，我在另一个名为include的目录中拥有API和REST客户端所需的资源。因此结构如下：example.com/api/v0.2/method_name/和on.htaccess，我要确保遵循.htaccess文件中硬编码的api版本的所有内容都保存在查询字符串参数中。 我不确定这是否适合实时应用程序，因为它也需要手动更改客户端的URL端点。因此，我的问题是：

这是API版本控制的正确方法吗？ 如果是，我保留它，我如何处理过时的URL。比如说，应用程序是实时的，我将API更新为v0.3，但是安装了应用程序的客户端将访问v0.2并返回404响应代码？ 还有更优雅的解决方案吗？一定是这样。 编辑：有些资源位于api文件夹本身之外，可以说是根include文件夹中

---

编辑2：我的API的目标是被移动应用程序使用，而不是公开使用

虽然我认为这些问题主要是基于观点的，但我还是要尝试一下

我认为这是一种有效的方法，我也见过其他人使用它， 包括微软

当需要更新API时，您可以给出404 返回并解释新API位于新地址。 然而，仅仅停用一个API版本通常是个坏主意；你 至少要给客户端开发人员足够的时间切换 在旧API（如果有的话）退役之前，请访问新API

一个更优雅的解决方案是将API保持在一个级别 地址，并根据需要进行更新，并添加到其中，而不是 尽可能更换。继续支持as的过时功能 尽可能长，并与客户开发人员进行开放式沟通 关于某个方法何时不再有效

---

只是我的意见，随你怎么做…

你有没有看右边相关部分的链接？例如，其中一些问题对我来说太复杂了。谢谢你的回答。我没有提到RESTful API不是公共的。在可预见的未来，它只会被移动应用程序使用。它也是私有的，因此只有注册的API密钥才能访问它的资源。但我仍然认为，对于公开的移动应用程序来说，保持向后兼容性也是一个好主意。因为过时的功能和要求用户更新应用程序也会激怒他们。现在，如果我支持一个功能，我是否也不必保留资源？这意味着保留一个v0.2文件夹及其所需的所有资源。我同意，通过尽可能长时间地添加现有功能来保持相同的版本。如果需要更改API，请创建新版本并弃用旧版本，但不要删除它。保持这种状态，给开发者3-6个月的时间来跟上进度。另外，我认为当API被替换时，3xx比4xx好。谢谢您的回复，@Paaske。但是，你看，我并不是在制作一个可公开使用的API。它只会被我的移动应用程序使用。您建议我如何保持API的向后兼容性？此外，如果我更改了404所在目录的版本，服务器将自动抛出404，因为它找不到该文件。好的，但您仍然不应该更改旧文件夹，只需添加一个新文件夹。然后，这两个文件夹可以使用一段时间，直到所有用户都更新到应用程序的最新版本，而应用程序现在使用的是最新版本的API。然后你可以删除旧版本的文件夹。这不会造成可维护性问题吗？我不仅要为每个版本维护单独的文件和目录，还要维护多个版本，比如一个配置文件。在我看来，这是一个繁忙的解决方案。