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

[Dan Berindei (Jira)]

     [ https://issues.redhat.com/browse/ISPN-11969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Berindei updated ISPN-11969:
--------------------------------
      Component/s: REST
    Fix Version/s: 12.0.0.Final


> 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.0.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}}.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)