几乎所有API都处理不同的发行版本。通常你会看到这种版本：
但是我没有找到一个描述如何在Spring堆栈中组织它们的源代码。我想在每个控制器上都有像/v1这样的@RequestMapping("/v1/questions")前缀并不是最好的方法。
想象一下，只有当前版本的@Service层（在我们的案例中为V2）。
我们的服务应该处理V1和V2的请求。唯一的变化是V2在问题实体上添加了一个新字段（这意味着V1问题可以很容易地转换为V2问题）。
现在的问题是：
~.web.* @Controller？~.web.* @Controller？以RequestMapping的方式？或者是否可以使用上下文配置它们：在V1 java包中进行组件扫描？一个例子看起来像这样（我在各处添加了包）：
// on V1 Question look like this:
public class project.domain.Question
{
private String question;
}
// on v2 Question looks like this:
public class project.domain.Question
{
private String question;
private Date creationDate;
}
@Service
public class project.service.QuestionService
{
public long create(Question q) {...};
public Question read(long id) {...};
public void remove(long id) {...};
public void update(Question qd) {...};
}
@Controller
@RequestMapping("/v2/question")
public class project.web.v2.QuestionController
{
@Autowired
project.service.QuestionService questionService;
@RequestMapping(method = RequestMethod.POST)
@ResponseBody
public long create(Question q)
{
return questionService.create(q);
}
}
@Controller
@RequestMapping("/v1/question")
public class project.web.v1.QuestionController
{
@Autowired
project.service.QuestionService questionService;
@RequestMapping(method = RequestMethod.POST)
@ResponseBody
public long create(Question q)
{
// this will not work, because the v1 haven't had the 'creationDate' field.
return questionService.create(q);
}
}
版本化REST API是一个复杂的问题。首先，让我们确定一些版本化的高级方法：
考虑到这一点，让我们考虑一些目标:(直接来自API Evolution）
接下来，让我们考虑对API的一些可能的更改：
该语言应明确设计，并考虑到前向兼容性，客户应忽略他们不理解的信息。
因此，将信息添加到资源的表示不是不兼容的更改。
对语言的此类扩展/更改可以利用Accept标头和内容协商 - 使用自定义供应商MIME媒体类型对表示进行版本控制。这些文章在这方面更加深入：API Versioning，Versioning REST Web Services。
因此，这确实代表了客户端的不兼容更改 - 它必须请求新的表示并理解新的语义，但URI空间将保持稳定并且不会受到影响。
这些是资源含义的变化以及它们之间的关系。在这种情况下，我们可以考虑更改Resources和URI结构之间的映射。但是，这仍然不一定意味着在URI中使用版本指示符。
REST API应遵循HATEOAS约束 - 大多数URI应由客户端发现，而不是硬编码。更改此类URI不应被视为不兼容的更改 - 新URI可以替换旧URI，并且客户端将能够重新发现URI并仍然起作用。
对于这种彻底的更改，URI中的版本指示符是最后的解决方案。
DispatcherServlets的web上下文可能有意义，因为它允许URI空间的清晰分离@RequestMapping的新属性 - produces和consumes也很有帮助其他一些非常有用的资源：
希望这可以帮助。
这就是我们在项目中所做的事情：
{developer}.{customer}.{project}.core - @Service和@Dao的东西
{developer}.{customer}.{project}.core.model - 模型实体，这是整个core包的工作原理
{developer}.{customer}.{project}.api.rest.v1.resource - @Controller REST资源
{developer}.{customer}.{project}.api.rest.v1.model - v1 API的DTO
{developer}.{customer}.{project}.api.rest.v1.mapper - DTO与核心模型实体之间的映射器如果核心发展（并且它不断发展），它只涉及API映射器。资源和DTO保持不变。
自从我们引入v1 API以来，我们的核心及其模型发生了很大变化。当然，我们正在对v1进行一些向后兼容的更改 - 引入新的搜索参数，资源或基于参数的响应修饰符。
而且我不得不说我们还没有进入v2 API - 但是它已经落后了，因为v1已经是史前的，并且在某些方面与核心模型不兼容（不同的模型属性，不同的模型关系，过时和不一致的命名。 ..）。
如果我们想在版本之间重用一些代码，我可以想象它会放在{developer}.{customer}.{project}.api.rest.base中。
请求映射在每个REST资源中手动编写。所以每个资源的映射都有/v1/...。
我并不完全相信我们的方式是正确的解决方案，甚至接近它。但这很简单。我们将看到v2将如何适应。