ture, clients that use the older version of the schema can still validate and process newer ver-
sions of the format as they receive them.
As the schema evolves, new attributes and elements can be added, but they should be made
optional. For example:
<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" //>
<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" />
Here, we have added the street, city, state, and zip elements to our schema, but have made
them optional. This allows older clients to still PUT and POST older, yet valid, versions of
the data format.
If you combine flexible, backward-compatible schemas with media type versions, you truly
have an evolvable system of data formats. Clients that are version-aware can use the media
type version scheme to request specific versions of your data formats. Clients that are not
version-aware can still request and send the version of the format they understand.
In this chapter, you learned how HTTP Content Negotiation works and how you can write
JAX-RS-based web services that take advantage of this feature. You saw how clients can
provide a list of preferences for data format, language, and encoding. You also saw that JAX-
RS has implicit and explicit ways for dealing with conneg. Finally, we discussed general ar-
chitectural guidelines for modeling your data formats and defining your own media types.