Jason Gerlowski created SOLR-17351:
--------------------------------------
Summary: Cosmetic changes to v2 filestore "get file" API
Key: SOLR-17351
URL: https://issues.apache.org/jira/browse/SOLR-17351
Project: Solr
Issue Type: Sub-task
Components: Package Manager, v2 API
Affects Versions: 9.6.1
Reporter: Jason Gerlowski
Solr's filestore APIs fit well with the REST-ful design we're targeting with
our v2 APIs, with one large exception: the "get file" API current available at
{{GET /api/node/files/somePath.txt}}. This API stands out for a few reasons:
1. It uses a different path-prefix than all other filestore APIs. (i.e.
{{/api/node/files}} instead of {{/api/cluster/files}})
2. It exposes 4 or 5 conceptually distinct operations. Obviously in the
"default" case it allows callers to retrieve filestore contents, but based on
query params it can instead:
- return filestore entry metadata (when {{meta=true}} is specified)
- instruct the receiving Solr node to pull a file from another node's
filestore and cache it locally (when {{getFrom=someOtherNode}} is specified)
- instruct the receiving Solr node to push its cached copy of a file out to
all other Solr nodes (when {{sync=true}} is specified)
3. Even in the default case of returning "raw" filestore contents, the API can
provide two different styles of response:
- if {{wt=json}} is specified Solr will take the filestore entry bytes,
attempt to stringify them, and then return a JSON object that uses this string
as the value for a "response" key. It's unclear how this would work for binary
content
- for all other values of "wt", the API will return the raw file content.
We should reconsider this endpoint and see if it can't be massaged into being
more in line with our other v2 APIs. Some cosmetic tweaks will go a long way,
but the biggest benefit is likely to come from breaking the endpoint up into
multiple distinct APIs. In its current form, the API returns such a variety of
responses that it's hard to write client code for. (I suspect this is the main
reason these "filestore" APIs were never made available in SolrJ.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
