JAX-RS入门 十： 兼容与演进

网络服务会随着时间的发展再不断进化，例如：添加新的特性；扩展数据集；数据格式的改变和演化。你怎么来管理这些变化呢？怎么让以前的用户能够在旧版本上运行呢？

 

将应用模块会可以解决这些问题中的大多数。下面就讨论一些在开发应用时需要有的设计和决策，以适应这些可能的变化。

 

一、创建新的Media Type

 

REST的一个重要准则是将你的资源的复杂性隐藏在你的变换数据后面。然后URI可以是不变的，但是数据格式会不变演进。需要记住的、非常重要的一点就是当你做计划时，考虑好你的应用怎么去应对版本管理。

 

因为复杂性限制在数据格式中，客户端可以使用Media type去请求不同的格式版本。一个常用的，致力于解决这个问题的方法就是使用你的应用去定义一个新的Media Type。 一个指导准则就是使用vnd前缀，一个新格式的名字，和一个具体的，以+号分隔的Media Type后缀。假设我们说Red Hat公司有一个管理用户的特定的xml格式，则Media Type名可能如下：

 

application/vnd.rht.customers+xml

vnd表示供应商，rht表示Red Hat，customers代表我们的用户数据格式。以+xml结尾，让用户知道这个数据格式是基于xml的。同样的对Json：

 

application/vnd.rht.customers+json

有了一个新的Media Type，下面就是追加版本信息，这样老的用户还可以使用老版本的数据：

 

application/vnd.rht.customers+xml;version=1.0

保持子类型名不变，通过指定一个属性来指定版本号。这样随着时候的推移，只需要提升版本号以表示数据的格式变化。

 

二、灵活的Schema

 

通过在Media Type中使用版本属性，我们就可以很好的管理和缓解服务或应用的变化。 不过，虽然在Media Type版本信息是相当有用的，但是它不应该是你管理变化的第一选择。 当定义和初始化一个新的数据格式时，尤其要注释向前兼容性。

 

例如对于XML Schema，最初的Schema应允许每个Schema类型能够扩展或自定义新的元素或属性。例如：

<schema targetNamespace="http://www.example.org/customer"
xmlns="http://www.w3.org/2001/XMLSchema">
    <element name="customer" type="customerType"/>
    <complexType name="customerType">
        <attribute name="id" use="required" type="string"/>
        <anyAttribute/>
        <element name="first" type="string" minOccurs="1"/>
        <element name="last" type="string" minOccurs="1"/>
        <any/>
    </complexType>
</schema>

上例中，Schema允许添加任意的属性和任意的元素。如果新版本的数据类型保留了最初的数据结构，则老版本的客户端仍然可以验证和处理他们接收到的新的数据格式。

 

例如以下为新的Schema，定义了新的属性和元素，但是必须注意：这些新元素或属性需要设置为Optional的：

<schema targetNamespace="http://www.example.org/customer"
xmlns="http://www.w3.org/2001/XMLSchema">
    <element name="customer" type="customerType"/>
    <complexType name="customerType">
        <attribute name="id" use="required" type="string"/>
        <anyAttribute/>
        <element name="first" type="string" minOccurs="1"/>
        <element name="last" type="string" minOccurs="1"/>
        <STRONG><element name="street" type="string" minOccurs="0"/>
        <element name="city" type="string" minOccurs="0"/>
        <element name="state" type="string" minOccurs="0"/>
        <element name="zip" type="string" minOccurs="0"/></STRONG>
        <any/>
    </complexType>
</schema>

这里我们新增加了一些元素，并使得他们是可选的。因此旧版本依然可以PUT和POST旧的、仍然有效的数据格式。

 

如果你结合了可扩展的、向前兼容的Schema以及Media Type版本，那你就真正拥有了一个数据格式可升级的系统。版本依赖的客户可以使用Media Type版本去请求指定的版本数据；未依赖于版本的客户可以请求和发送他们理解的版本。