Once I get the core-container split out into it's own provider/service/whatever started by a context listener, we should do v3 as a servlet giving us a clean slate, and easy access to verbs. I suspect v2 was made much more difficult by the fact that it had to co-exist with a lot of other code inside a filter.
On Fri, Nov 5, 2021 at 6:04 AM Jan Høydahl <[email protected]> wrote: > +1 to experimental > > If we want to be more standards-based, embrace OpenAPI and perhaps more > standardized RBAC frameworks, then I believe there will be a v3 API based > on JAX-RS or something, with more active use of http verbs. > While v2 is harder for devs to use and remember, it has somewhat better > practices wrt no mutating state with GET requests, which is the worst thing > about v1 imo. > > Even a v2 or v3 API can have some "convenience" things built-in. I.e. > allowing common operations with a simple URL param rather than having to > add a POST body for all. > > Jan > > 5. nov. 2021 kl. 10:54 skrev Eric Pugh <[email protected]>: > > I can live with “experimental” ;-) > > On Nov 4, 2021, at 6:42 PM, Shawn Heisey <[email protected]> wrote: > > On 11/4/21 1:20 PM, Jason Gerlowski wrote: > > With that in mind, I think the next steps here should probably be to: > > 1. decide what label or term we want to go with ("evolving"? > "experimental"? "beta"?), and > 2. figure out what the best way to publicize change in policy. > > For (1) my vote is probably still "experimental". If others care > enough to chime in though I'm happy to go with whatever's most > popular. > > > From what I have seen, an experimental designation is the right way to go > for v2. If we don't do that, then I think we have to cease development on > v2 and create something like v3, designating THAT as experimental. I don't > see much value in coming up with a synonym that means the same thing. > > Eric expressed some concern that "experimental" implies that v2 might > not get adopted. IMO that implication might not be a bad thing; > Houston is talking about making the APIs more RESTful, Tim wants to > add OpenAPI support, and there were lots of other changes suggested in > this thread alone. > > > > Also from what I have seen, v2 is not ready for adoption yet, so I think > we call it experimental and get ready to really overhaul it. I believe I > heard somebody say it's incomplete compared to the original API, plus the > community has a lot of ideas about major additions and/or fundamental > changes in its design. If we eat our own dog food by using the v2 API in > things like SolrJ, scripts, and the admin UI, we are more likely to try and > come up with stable designs that don't need to be thrown out frequently. > The experimental designation would make it possible for us to throw > something out and begin again if we find that the existing design of that > component is too limiting. > > I would like to eventually (in 10.0, maybe) get to a point where we > declare the original API as deprecated and remove the experimental > designation from v2. At that point we only make new bells and whistles > available in v2 ... and then a major version or two after that, we remove > the old API entirely. Backward compatibility is an important goal to strive > for, but it can't be maintained forever. > > This is possibly a pipe dream: I would like a new API to be able to do as > much as possible with URL parameters, only REQUIRING a body on the request > for things that are complex, or where a body is a natural pathway, like > indexing. Of course it should also be possible to put EVERYTHING into the > body and send no URL parameters at all. I think they call this wanting to > have my cake and eat it too. :) Like I said ... might be a pipe dream. > > Something I have found to be invaluable is the fact that a LOT of things > can be done and tested with the original API simply by typing a URL into a > browser. If everything MUST be done with a request body, I would find that > to be extremely inconvenient. If the community thinks that's the right > thing to do, then I will adapt. It's not all that difficult to send a body > with something like curl. And that requirement might make people more > cautious about how they interact with Solr. > > Thanks, > Shawn > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <[email protected]> > For additional commands, e-mail: [email protected] > <[email protected]> > > > _______________________ > *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467 > | http://www.opensourceconnections.com | My Free/Busy > <http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless > of whether attachments are marked as such. > > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
