为什么不让后端api路由从/api开始？
为什么我们想要/v1位？为什么不只是api/？你能举一个具体的例子吗？两者都有什么好处？
公开服务的主要挑战之一是处理API合同的更新。当API更改时，客户端可能不想更新其应用程序，因此版本控制策略变得至关重要。版本控制策略允许客户端继续使用现有的REST API，并在准备好后将其应用程序迁移到较新的API。
有四种常见的方法可以对RESTneneneba API进行版本化。
- 通过URI路径进行版本控制http://www.example.com/api/1/products
通过URI路径进行REST API版本控制版本RESTneneneba API的一种方法是在URI路径中包含版本号。
xMatters使用这种策略，Facebook、Twitter、Airbnb等公司的DevOps团队也使用这种策略。
API的内部版本使用1.2.3格式，因此如下所示：
少校。次要。补丁
主要版本：URI中使用的版本，表示对API的中断更改。在内部，新的主版本意味着创建一个新的API，版本号用于路由到正确的主机。次要版本和修补程序版本：这些版本对客户端是透明的，并在内部用于向后兼容的更新。它们通常在更改日志中进行通信，以向客户端通知新功能或错误修复。此解决方案通常使用URI路由来指向特定版本的API。因为缓存密钥(在这种情况下是URI(是按版本更改的，所以客户端可以轻松地缓存资源。当发布新版本的REST API时，它被视为缓存中的一个新条目。
优点：客户端可以轻松缓存资源缺点：这个解决方案在代码库中有相当大的足迹，因为引入突破性的更改意味着分支整个API
参考编号：https://www.xmatters.com/blog/blog-four-rest-api-versioning-strategies/#:~：text=客户端%20可能%20不%20需要%20，API%20何时%20准备就绪%20。