[jira] [Commented] (SOLR-17351) Cosmetic changes to v2 filestore "get file" API

["Jason Gerlowski (Jira)" <ji...@apache.org>]

    [ 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-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org