On 6/16/22 09:07, Gus Heck wrote:
I'm all for standardizing on v2 (or something like it) but one key
concern I have is that when the only access I have to a client's
server is via a web browser, possibly from a machine they control and
on which I can't install tools, I'd like the only barrier to my
running necessary admin commands is their (hopefully) configured
security controls (RBAC/JWT/whatever). It's a loss of functionality if
a REST client program, plugin or curl is *required*. Those tools are
good things, but the ability to fully control solr directly from a
browser (if properly authenticated) is a good feature we shouldn't lose.
I agree with this.
It's REALLY nice to be able to try things out with a browser, or to
issue infrequently-used admin requests with a browser. Or to send
somebody a URL with a note that says "This is what I am thinking." The
v1 API makes this possible, and I have abused it in this way a LOT. I
know someone is going to say "sending a body is trivial with curl." But
the person I am sending the message to may have absolutely no idea how
to use something like curl, and they may be on a stock windows setup
that doesn't have any of those cool tools available.
I'm OK with such fiddling happening via the admin UI ... but I don't
think the admin UI is as feature-complete as it needs to be for an API
that *requires* a body in the request to work. And it's very important
from my perspective that I can send a URL to someone that demonstrates
how to do something that will ultimately happen with a client that knows
how to send request bodies.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
