网络服务会随着时间的发展再不断进化,例如:添加新的特性;扩展数据集;数据格式的改变和演化。你怎么来管理这些变化呢?怎么让以前的用户能够在旧版本上运行呢?
将应用模块会可以解决这些问题中的大多数。下面就讨论一些在开发应用时需要有的设计和决策,以适应这些可能的变化。
一、创建新的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"/>
<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"/>
<any/>
</complexType>
</schema>
这里我们新增加了一些元素,并使得他们是可选的。因此旧版本依然可以PUT和POST旧的、仍然有效的数据格式。
如果你结合了可扩展的、向前兼容的Schema以及Media Type版本,那你就真正拥有了一个数据格式可升级的系统。版本依赖的客户可以使用Media Type版本去请求指定的版本数据;未依赖于版本的客户可以请求和发送他们理解的版本。