Details
-
Enhancement
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
Description
Our REST API currently has:
GET /rest/v2/caches/{cacheName}?action=search&query=...
or
POST /rest/v2/caches/{cacheName}?action=search
with a JSON in the body:
{ "query": "..."{color:#f8f8f2}}
this API does not allow for parameter replacement, which means having to pass the values directly in the query
for the POST variant we could introduce an additional parameters property. Depending on the use of ? or named arguments, this could either be an array (where the parameters are positional) or an object
Tristan:
{{{ "query": "FROM Entity WHERE value > ?" "parameters": [ 5 ]{color:#f8f8f2}}}}
or
{{{ "query": "FROM Entity WHERE value > :arg" "parameters": { "arg": 5 {color:#f8f8f2}}}}}
While the HTTP spec doesn't forbid passing a body with a GET, it is frowned upon. Elasticsearch, however, does exactly that.
For the GET, I would go for parameters in the URL query string
GET /rest/v2/caches/{cacheName}?action=search&query=...¶m=<p1>¶m=<p2>&...
This only supports positional parameters
For named parameters we could have a prefix
GET /rest/v2/caches/{cacheName}?action=search&query=...¶m.p1=<p1>¶m.p2=<p2>&...
Note that the maximum length of a URL is a limiting factor for the GET variant