Details
-
Sub-task
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
9.6.1
-
None
-
None
Description
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.)