[infinispan-issues] [Red Hat JIRA] (ISPN-11969) Find a replacement for the Key-Content-Type REST request header

Find a replacement for the Key-Content-Type REST request header --------------------------------------------------------------- Key: ISPN-11969 URL: https://issues.redhat.com/browse/ISPN-11969 Project: Infinispan Issue Type: Task Components: REST Reporter: Dan Berindei Priority: Major Fix For: 12.1.0.Final A REST URI should uniquely identify a resource. But in our server, the {{Key-Content-Type}} request header changes the way the URI is mapped to a cache key, so a single URI could be seen by the server as multiple different cache entries. The simplest solution would be to extend the URI of cache entries with a query parameter, e.g. {{/rest/v2/caches/<cache>/<key>?key-content-type=<media-type>}}. I have 2 small concerns with this solution: 1. When doing a POST request, browsers will put all the parameters in the request body instead of the location. I don't expect us to have browsers acting as clients, and the search request already does this, but something to keep in mind. 2. Although resource URIs can be anything, they are usually thought to include only the path part of the URL. Everybody knows query parameters affect `GET` requests, but the difference between `DELETE /rest/v2/caches/<cache>/<key>` and `DELETE /rest/v2/caches/<cache>/<key>?key-content-type=application/octet-stream` might be surprising to some. I would prefer to put the key media type in the path of the URI, e.g. {{/rest/v2/caches/<cache>/<key-content-type>/<key>}}. It also has a problem: it makes it look like encodings create separate namespaces, but they actually overlap, and the same logical "cache entry resource" can be accessed with multiple key content types. So perhaps we should instead say the {{/rest/v2/caches/<cache>/<key>}} resources are always {{text/plain;charset=UTF-8}} keys, and for any other content type the client should use a different resource, {{/rest/v2/caches/<cache>/entry/}} (the extra {{/}} may or may not be required to avoid clashing with regular keys). The {{/rest/v2/caches/<cache>/entry/}} resource would have {{key}} and {{key-content-type}} parameters that could be sent either in a `GET` query string or in a `POST` body. Note: Some key content types will have additional parameters to tell the server how to decode them, e.g. {{application/x-java-object;type=java.long.Double}}, or {{application/octet-stream;encoding=hex}}. I have created ISPN-11966 to deprecate the {{application/x-java-object}} handling, and ISPN-11968 to deprecate the {{encoding}} parameter in {{application/octet-stream}}.