对 JavaScript 单页 Web 应用程序进行版本控制？ （查询字符串）
我有一个带有一些静态路由的单页应用程序，例如：
example.org/#!/tools/
example.org/#!/stories/story-1/
这些是不需要任何版本控制的路由示例。 “页面”要么存在，要么已被重定向，要么不存在。
但是我还有其他想要版本化的资源（因为它们可以有内部状态 - 用大于 10 个参数的查询字符串表示）：
example.org/#!/tools/population-tool/ + ?a=b&c=d[...]
因为查询字符串参数可能会随着时间的推移而改变（因为该工具可能允许更多选项），我想向这些“页面”添加一个版本参数：
example.org/#!/tools/population-tool/ + ?v=1.1&a=b&c=d[...]
这样，当用户导航到没有任何内容的 URL 时，参数，默认状态和版本会自动添加：
example.org/#!/tools/population-tool/ =>
example.org/#!/tools/population-tool/ + version + default state
如果用户决定共享/添加此 URL 的书签，版本参数将始终允许我将参数从一个版本重新映射到另一个版本。
- 你能建议一个更好的方法吗？
也许版本应该是所有路由的 url 的一部分？
<块引用>example.org/#!/v1/tools/population-tool/
或者对查询字符串进行版本控制可能是错误的方法 共？也许我应该有一种方法来猜测 根据给定的参数正确的“API”？
谢谢。
I have a Single Page App with some static routes such as:
example.org/#!/tools/
example.org/#!/stories/story-1/
These are examples of routes that don't need any versioning. Either the "page" exists, it has been redirected or it is non-existent.
But then I have other resources I'd like to version (because they can have internal states - denoted with a querystring of > 10 parameters):
example.org/#!/tools/population-tool/ + ?a=b&c=d[...]
Because the querystring paramaters might change over time (as the tool might allow more options), I'd like to add a version parameter to these "pages":
example.org/#!/tools/population-tool/ + ?v=1.1&a=b&c=d[...]
So that when a user navigates to the URL without any parameters, the default state and version is automatically added:
example.org/#!/tools/population-tool/ =>
example.org/#!/tools/population-tool/ + version + default state
In case the user decides to share/bookmark this URL, the version paramater will always allow me to remap the paramaters from one version to another.
- Can you suggest a better approach?
Perhaps the version should be a part of the url for all routes?
example.org/#!/v1/tools/population-tool/
Or perhaps versioning the querystring is the wrong approach
altogether? Perhaps I should have a method that guesstimates the
right "API" based on the parameters given?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从参数猜测正确的 API 可能很乏味，并且会导致路由子系统出现不必要的复杂性。在 URL 中明确指定版本信息会更加清晰。
现在要遵循的方法是 1 还是 2 在很大程度上取决于个人喜好。在我看来，这取决于最终用户对应用程序版本的感知程度。如果您的最终用户没有察觉到前端的变化（即，如果您遵循 MVC 架构，并且变化仅是模型层，而视图层保持不变，那么更推荐使用方法 1。对于用户来说，了解他正在使用哪个版本很重要，或者如果最终用户可见的用户界面在不同版本中有所不同，那么方法 2 是更好的选择，因为它将版本信息放在 url 中的显着位置
。查看它可以询问应用程序状态是否版本之间的 url（无查询参数）表示应用程序状态，如果答案为真，则应遵循第二种方法，但是如果版本信息是从主应用程序代码中抽象出来的，并且仅与某些特定相关。抽象的子部分，例如只有几个模型类，则应遵循方法 1。
Guessing the right API from parameters can be tedious and will lead to unnecessary complexities in your routing sub-system. It is much more cleaner to having the version information clearly specified in the URL.
Now whether the approach to be followed is 1 or 2 is much of a matter of taste. In my opinion it depends on how perceivable your application version is to the end user. If your end user does not perceive an change in the front-end (ie. if you are following an MVC architecture and the change is only the Model layer while the view layer remains unchanged then approach 1 is more recommended. Where as if it is important for the user to be aware of which version he is using or if the user-interface visible to end user is different across versions then approach 2 is a better option because it puts the version information in a prominent position in the url.
Another way of looking at it can be asking the question if application state is different between versions. A url (sans the query parameters) represents the application state and in case the answer is true then 2nd approach should be followed. However if the version information is abstracted away from the main application code and is relevant only to certain abstracted sub-sections eg. only a few model classes then approach 1 should be followed.