epugh commented on code in PR #4264:
URL: https://github.com/apache/solr/pull/4264#discussion_r3068027623
##########
solr/api/src/java/org/apache/solr/client/api/endpoint/ConfigsetsApi.java:
##########
@@ -71,6 +79,46 @@ SolrJerseyResponse
deleteConfigSet(@PathParam("configSetName") String configSetN
throws Exception;
}
+ /**
+ * V2 API definition for downloading an existing configset as a ZIP archive.
+ *
+ * <p>Equivalent to GET /api/configsets/{configSetName}/download
+ */
+ @Path("/configsets/{configSetName}")
+ interface Download {
+ @GET
+ @Path("/download")
Review Comment:
so we could, and I was thinking about it and then asked Claude for soem
suggestions, and he kind of came back to "/download" is easy. Here is the
write up:
RESTful Alternatives
### Option 1: Keep current design ✅ (Recommended)
```
GET /api/configsets → List (JSON)
GET /api/configsets/{name}/download → Download ZIP
GET /api/configsets/{name}/{filePath} → Get single file
```
**Pros:**
- Explicit and unambiguous
- Self-documenting (`/download` tells you what it does)
- No conflicts with file paths
- Common pattern (GitHub uses `/archive`, GitLab uses `/repository/archive`,
etc.)
**Cons:**
- Not purely resource-oriented REST
### Option 2: Use `/files` sub-resource
```
GET /api/configsets/{name} → Metadata (JSON) - NEW
GET /api/configsets/{name}/files → Download all as ZIP
GET /api/configsets/{name}/files/{path} → Get single file
```
**Pros:**
- More RESTful hierarchy
- Room for metadata endpoint
**Cons:**
- Breaking change to existing API
- More complex paths
### Option 3: Content negotiation (Pure REST)
```
GET /api/configsets/{name}
Accept: application/json → Metadata
Accept: application/zip → ZIP download
```
**Pros:**
- True REST content negotiation
**Cons:**
- Solr doesn't typically use `Accept` headers this way
- Harder to use with curl/browsers
- Still conflicts with `/{filePath}` pattern
## Recommendation
**Keep the current design** (`/download`) because:
1. ✅ **Unambiguous** - no path conflicts
2. ✅ **Self-documenting** - clear what you get back
3. ✅ **Pragmatic** - works well without complex content negotiation
4. ✅ **Common pattern** - many APIs use action-style endpoints for different
representations
5. ✅ **Backward compatible** - if we add metadata later, we can use `GET
/api/configsets/{name}` for JSON
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
