@Shawn Is there a need to make it easier to invoke POST/PUT/DELETE methods ? absolutely yes.
But, that should be a separate effort. Most likely , we would keep the V1 API around for a while and users could resort to those APIs if they wish to. However, the discussion is around whether we should migrate our documentation and clients to use V2 as a de-facto interface On Sat, Jun 18, 2022 at 5:35 AM Shawn Heisey <apa...@elyograg.org> wrote: > On 6/17/2022 12:15 PM, Jason Gerlowski wrote: > > Hey Shawn, Gus: I agree that "just sharing a URL" is dead simple and > > can help for less-sophisticated users, or in more locked-down (i.e. > > dev tool-less) environments. But I agree with Noble's point: using > > the full range of HTTP methods is about as uniquitous "standard > > practice" as it gets. We might help less-technically-saavy users by > > writing a GET-only API, but that would end up being less intuitive for > > the majority of users who are familiar with and expect that standard > > practice. > > I have some mixed feelings about making it impossible to take actions > with a GET. For index updates, I don't have a problem with those > requiring POST, mostly because that is required now with v1. Same for > the Config API or the Schema API. What you're saying about properly > using all the HTTP methods makes sense and required if we want the API > to be something modern like REST. > > One way could be to have all "manual" browser-based requests actually go > through the admin UI. So clicking a button in the admin UI would take > you to a URL that if repeated, would take exactly the same action, and > that would be the URL that gets shared to demonstrate things. Similar > to what happens when using the "query" interface in the admin UI now. > > The admin UI code running in the browser would translate those requests > into the appropriate v2 call, including a POST body if that is needed. > I am imagining all the required parameters being after the # in the URL, > which only the browser ever sees. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > -- ----------------------------------------------------- Noble Paul
