cc @dmitshur

Seems reasonable to mirror the URL. I think that just means routing the request to the same code.

This does sound like a bug in Artifactory though. Query strings are valid parts of URLs. They shouldn't be ignored for caching.

The proposed scheme has some convenience improvements in specific cases, but I think the bar for introducing and perpetually maintaining a mirror of an API needs to be higher than minor convenience improvements.

but trips up mirror sites

If this can be fixed in those mirror sites (as Jay suggested), that seems like a better location for the fix.

As one example of API designs with similar properties, GitHub API v3 uses JSON responses also without a ".json" suffix in the URL, and accepts query parameters, such as https://api.github.com/repos/golang/go/events?per_page=3.

If this can be fixed in those mirror sites (as Jay suggested), that seems like a better location for the fix.

I don't disagree, although in practice I'm certain it's going to be a much longer process to get Artifactory (and likely other software) to change how they do caching than it would be to use a different URL for this server. Plan is to attempt both 😁 .

As one example of API designs with similar properties, GitHub API v3 uses JSON responses also without a ".json" suffix in the URL, and accepts query parameters, such as api.github.com/repos/golang/go/events?per_page=3.

I guess it depends whether one treats this as a file that is occasionally updated, or an API call (or both). Artifactory treats it as the former (probably because caching API calls in general doesn't make so much sense). I was thinking of this like the Node.js equivalent (https://nodejs.org/dist/index.json).