restapi的Nginx缓存

我们有一个移动应用程序，它调用RESTAPI来获取要在移动主屏幕上显示的磁贴列表。身份验证机制是身份验证令牌，我们使用它唯一地标识用户。菜单会根据应用程序的版本不断变化。为此，我们有两种方法

/api/tilemenus

（仅传递验证头，而非版本）

检索auth header并在db表中查找应用程序的版本（我们还将用户版本存储在数据库中，并在用户升级应用程序时进行更新），并相应地返回数据

/api/tilemenus/1.2.2

（同时传递auth头和版本，因为客户端知道其版本本身）

在这里，不需要数据库查找，因为REST请求本身正在传递版本

哪种方法更好？我认为方法2更好，因为我们可以传递缓存头来缓存每个版本的API。对于方法1，当用户升级应用程序时，没有隐式方法放弃这种缓存。

在我看来，#2更好，因为您强制保证特定URL始终返回相同的资源/数据，并且，是的，您可以安全地缓存它

另外，只需分析HTTP服务器日志，就可以更轻松地跟踪版本使用情况

---

而且它甚至省去了跟踪用户版本的工作，因为#2通过请求URL本身使其显式化

在URI路径中传递API版本是很常见的（也请查看）。我建议使用第二个选项，尽管将其重写为

/api/1.2.2/tilemenus

，这看起来更类似于api在一系列流行网站上的操作方式。

互动程序是否也因用户而异，还是仅由版本决定互动程序？不，它们不会因用户而异。版本决定标题如果是这样，我建议第二种方法。顺便说一句，我会对此采取不同的方法。我不会从API中获取Tile，但会将其捆绑到应用程序中。我们希望能够不时更新每个版本的Tile…我更喜欢第二种方法。