When we think of HTTP and content negotiation most of us probably immediately think of mime-types. Agreeing upon the mime-type is indeed part of the HTTP conversation between a client and a server. However HTTP has also had an even finer grained content negotiation mechanism called the relative quality factor or 'q' factor for short. 'q' factors are so far not that well supported by browsers and are even more unknown to most developers. Using a q-factor, a client can specify a preference for the mime-type they want if they are able to support multiple mime-types (let's say to state a preference for PNG over JPG). The 'q' factor is essentially a number between 0.0 and 1.0 tacked onto the mime-type. A higher value indicates a more preferred mime-type. Similarly the server can also indicate what mime-type it prefers to send as a response by specifying a 'qs' factor or quality of source factor. The best written explanation of 'q' factors that I could find is here. Note that the article also points out the somewhat obscure nature and poor browser support for 'q' factor based negotiation in the web world so far. It does however point out the fact that Apache httpd has long had strong support for 'q' factors.
'q' factor based negotiation can be very valuable in REST. It can help you write a more robust service API. For example, you could support both JSON and XML for a resource and then state that you prefer JSON over XML if the client supports both. Similarly you can write more powerful clients that can flexibly process multiple content types. These capabilities are especially helpful while writing public APIs with REST or dealing with heterogeneous clients that you cannot completely predict. The same is true on the client side as well especially while dealing with third-party services. The good news for you is that JAX-RS 2 and Java EE 7 has strong support for 'q' factor based content negotiation. Sam Sepassi did a very nice job explaining the feature in a recent article. You should give it a read and consider using it if you have a good use case for the feature.