[
https://issues.apache.org/jira/browse/SOLR-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17909741#comment-17909741
]
Jason Gerlowski commented on SOLR-17351:
----------------------------------------
Started thinking about this again after some [recent discussion in
Slack|https://the-asf.slack.com/archives/CEKUCUNE9/p1735936717913429?thread_ts=1735927175.702769&cid=CEKUCUNE9].
I proposed above that we take the existing API and break it up into multiple
endpoints. Here's one option for how that could be done, that could be done in
a backcompat-friendly way without too much effort. At a high-level, the idea
is to introduce a "filestore" path segment, which can hold different sub paths
underneath to support the different ops:
# Tweak existing filestore APIs to take an (optional in 9.x) "filestore" path
segment. e.g. Delete-file would become {{DELETE
/api/cluster/filestore/files/some/path.txt}}. (This could be a simple tweak in
the '@Path' JAX-RS annotation for these methods)
# Add a "get file content" API at {{GET
/api/cluster/filestore/files/some/path.txt}}.
## This would only support fetching raw file contents. The special JSON-ified
response with wt=json would not be available at this new path.
# Add a "get file metadata" API at {{GET
/api/cluster/filestore/metadata/some/path.txt}}
# Add a "filestore commands" API for syncing and pulling file contents at
{{POST /api/cluster/filestore/commands?<qParams>}}
Let me know what you guys think; I can try to put together a draft of this soon
if I find time.
> 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
> Priority: Minor
>
> 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
