如何在sails.js中维护多个API版本 [英] How to maintain multiple API versions in sails.js

问题描述

在使用sails.js 时，有没有人有关于维护多个API 版本的想法?想象一个简单的例子，如:

Does anyone have ideas on maintaining multiple versions of your API when using sails.js? Imagine a simple example like:

// Request
GET /api/v1/catVids?min_view_count=10000

// Response
[{"video_title": "top cat fails"}, {"video_title": "funny-ass cats"}] 

用户正在积极使用 API 的 v1，但现在需求发生了一些变化，这会破坏现有功能.例如，属性名称更改.所以现在我们需要利用不同的控制器来满足这种新行为的请求.我想要做的是让两个 API 共存，这样就不会破坏向后兼容性.

Users are actively consuming v1 of the API but something has now changed in the requirements that will break existing functionality. For example, an attribute name change. So now we need to utilize a different controller to fulfill requests for this new behavior. What I would like to do is have both APIs co-exist so backwards compatibility is not broken.

// Request
GET /api/v2/catVids?minimum_view_count=10000

// Response
[{"title": "top cat fails"}, {"title": "funny-ass cats"}] 

但是，我不确定实现这一点的最佳方式.我认为可行的一种方法是在sails 应用程序中使用以下目录设置:

However, I'm unsure on the best way to implement this. One way I think it could work is to use the following directory setup within the sails app:

api/
|-- controllers/
|---- v1/
|------ CatController.js
|---- v2/
|------ CatController.js
|-- models/
|---- v1/
|------ Cat.js
|---- v2/
|------ Cat.js

我只是想知道是否有其他人遇到过类似的情况或对此主题有任何建议.

I'm just wondering if anyone else has ran into a similar scenario or has any suggestions on the topic.

推荐答案

您可以像示例中那样将控制器放在子目录中，因为 Sails 完全支持嵌套控制器.但是，由于嵌套模型会引起歧义，因此并未完全支持嵌套模型(请参阅 this评论).如果您将两个名为 Cat.js 的模型文件放在不同的子文件夹中，它们会发生冲突，并且当 Sails 抬起时，第二个将覆盖内存中的第一个.

You can get away with putting your controllers in subdirectories as in your example, because nested controllers are fully supported by Sails. However, nested models are not fully supported because of the ambiguity they would cause (see this comment on the matter). If you put two model files both named Cat.js in separate subfolders, they'll collide and the second one will overwrite the first in memory when Sails lifts.

不过，这是一个学术观点，因为无论如何您都需要某种方式在代码中区分您的两个模型版本.也就是说，在 v1 控制器中，您需要确保引用 v1 Cat 模型，对于 v2 也是如此.最简单的解决方案是使用您示例中的方案，但为您的模型(或至少 v1 之后的所有内容)添加后缀:

That's sort of an academic point though, since you'll need some way to distinguish between your two model versions anyway in code. That is, in your v1 controller you'll want to make sure you're referencing your v1 Cat model, and likewise for v2. The simplest solution would be to go with a scheme like you have in your example, but add a suffix to your models (or at least everything after v1):

api/
|-- controllers/
|---- v1/
|------ CatController.js
|---- v2/
|------ CatController.js
|-- models/
|---- v1/
|------ Cat.js
|---- v2/
|------ Cat_v2.js

Sails 将忽略模型的子文件夹，因此为了确保您的蓝图按您想要的方式工作，您可以向控制器添加 _config 属性以强制它们使用正确的模型.

The subfolder for the models will be ignored by Sails, so to make sure your blueprints work the way you want, you can add a _config property to your controllers to force them to use the correct model.

api/controllers/v1/CatController.js:

module.exports = {
  _config: {
    model: 'cat'
  },
  ...
}

api/controllers/v2/CatController.js:

module.exports = {
  _config: {
    model: 'cat_v2'
  },
  ...
}

更新(Sails 1.0)

_config 在控制器中的使用在 Sails 1.0 中不再有效.相反，您可以使用 parseBlueprintOptions 配置函数 设置蓝图操作的模型，例如:

Update (for Sails 1.0)

The usage of _config in a controller is no longer valid in Sails 1.0. Instead, you can use the parseBlueprintOptions config function to set which model a blueprint operates on, e.g.:

parseBlueprintOptions: function(req) {

  // Get the default query options.
  var queryOptions = req._sails.hooks.blueprints.parseBlueprintOptions(req);

  // Add the _v2 suffix to the `using` property.
  queryOptions.using = queryOptions.using + '_v2';

  return queryOptions;

}

这篇关于如何在sails.js中维护多个API版本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！