Content-type parameters - not working

The HTTP specification includes content-types with parameters, the implementation of Jersey does not support the use of these parameter as we understand it - see [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html)

We are using content-type parameters to support backwards compatibility in the individual endpoint, thus making it possible to ensure that clients having a need to continue using an older version of content from the same endpoint can do so by means of using the accept header correctly.
This allows an endpoint to evolve without demanding that every client must upgrade its understanding of the changed format for a given resource endpoint.

A version of person json retrieved from a GET operation to the example.com/persons/john-doe could over time be using content-type(s)

```
application/hal+json;concept=person;v=0.9
…
application/hal+json;concept=person;v=1.0
application/hal+json;concept=person;v=1.1
application/hal+json;concept=person;v=1.2
…
application/hal+json;concept=person;v=2.0
```

Different versions of the Person json contents have their own version, that can be used by clients to get the version they understand. The Accept header is used to map from the requested content-type to the correctly annotated function in the REST API. Please see the example below.

We are deploying in multiple containers, the RESTEasy implementation do support this already, but it seems like Jersey has not yet implemented this support yet.

We therefore suggests that this is implemented in Jersey

**Example:**
_Example works in RESTEasy, but not in Jersey_.

We are using the REST API is working with a representation of the model classes (POJOs) suitable for communication with clients eg. with content-type defined as “application/hal+json” and thus communicated as json using the HAL format. The HAL format is used for the GET verb to support HATEOAS. The example underneath shows the use of the default content-type which is expressed as either "application/hal+json" as the more precise type or "application/json".

```
@GET
@Path("/{id}/children")
@Produces({ "application/hal+json","application/json"})
…
public PersonsRepresentation findChildren(@Context UriInfo uriInfo,
@PathParam("id") String id,
@QueryParam ("..
@DefaultValue(EMPTY_SEARCH_PARAM) String "..) {
…
}
```

The matching of methods is done on the basis of the Accept header set on the client side and the produces annotation on the server side.
That is how we can support multiple versions of the same concept on the same resource. Having no specific generation header and a non-specific concept in the Accept headers:
Accept application/hal+json or Accept application/json
will result in a match of:

```
@GET
@Path("/{id}")
@Produces({ "application/hal+json;concept=person","application/hal+json","application/json"})
…
public Response getPerson(@Context Request request,
@PathParam("id") String id) {
…
//return service generation 1 concept version 1.2 as it is the newest
return getPersonG1V12(id);
}
```

The use of a specific content type specifying an older supported concept version:
Accept application/hal+json;concept=person;v=0.9
matches the older version directly

```
@GET
@Path("/{id}")
@Produces({ "application/hal+json;concept=person;v=0.9"})
..
public Response getPersonG1V09(@Context Request request,
@PathParam("id") String id) {
…
}
```

The use of another specific versions of concept
Accept application/hal+json;concept=person;v=1.2
will match that version directly

```
@GET
@Path("/{id}")
@Produces({ "application/hal+json;concept=person;v=1.2")
…
public Response getPersonG1V12(@Context Request request,
@PathParam("id") String id) {
…
}
```