Lost track of this convo for a while... but basically like what I read. I like that we've acknowledged the positive role of the UI, and I also very much like the use of http verbs for v2. The primary concern for me is that I can do most things via a browser connection to solr, so a kibana-like ui or even something simpler enhancing what we have on the Documents page could be sufficient. I find less use for sending folks URLs, but that point makes good sense too. Couple thoughts:
There is something of a risk to have a server that accepts non safe get requests. All these requests are contrary to the HTTP specification ( https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.1). A crawler or browser accelerator that might prefetch pages could do very bad things if unleashed on an intranet where there was (for example) a wiki with instructions on how to maintain their deployed solr, despite only issuing get requests. So I also think it is a good idea if unsafe gets can be turned off for folks who wish to guard against this (say on prod machines). Another thought I would like to float is that the current paradigm is that every api (v1, v2, query, json query, export, streaming, etc) is piped through our single servlet filter. If we are going to make serious changes to v2 (or do a v3) we might endeavor to put the new version into a servlet (which will have dedicated methods for verbs anyway). My changes to move CoreContainer into a servlet listener should make it possible to get a reference to CC in the servlet's init() method. There is probably a bunch of code that needs to be extracted to a reusable location so that v2 and v1 can continue to share appropriate code. But this would be a step towards simplifying the architecture so that functionality is organized into servlet classes of related logic and data rather than if-blocks and methods sharing all state in a few tightly coupled classes. It would be cool if (as one possible example) someday one had the option to build an index and then run a solr instance with the admin/update entirely disabled (i.e. servlets commented out of the web.xml and not even loaded). This would provide a read-only server without needing authentication. -Gus On Wed, Jul 20, 2022 at 6:59 PM Jan Høydahl <jan....@cominvent.com> wrote: > I'm still on holiday, but just chiming in to say I like and support the > direction here. I'm impressed by the structured and holistic approach on > this. > Also agree it is far better to have a consistent "new" v2 api in 9.x or > 10.0 at the expense of back-compat for existing v2 users -- maintaining > three versions is not going to happen. > > BTW: OpenAPI is the new name for what we earlier referred to as the > Swagger specification. The name Swagger is still the brand name for some > OpenAPI tooling - see > https://swagger.io/blog/api-strategy/difference-between-swagger-and-openapi/ > > Jan > > > 15. jul. 2022 kl. 05:17 skrev David Smiley <dsmi...@apache.org>: > > > > On Thu, Jul 14, 2022 at 4:31 PM Jason Gerlowski <gerlowsk...@gmail.com> > > wrote: > > > >>> I think it would be best to tackle one limited area first so we can see > >> it in practice both at the surface and implementation. > >> > >> I think that makes sense, assuming that by "tackling" you mean > >> updating the API path/verb/etc and moving the "real" logic over to the > >> v2 class? I'd rather we not take a "limited area" approach to getting > >> consensus around the API endpoint design itself, as IMO that'd produce > >> a less cohesive result. I don't think that was what you meant, but > >> just double-checking. > >> > > > > Sure -- API first. There may be some implementation realities that cause > > us to reconsider choices but we can take that as it happens. > > > > ~ David > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
