Re: v2 API "Broader Changes" and Next Steps

> A crawler ... could do very bad things if [unleashed on] a wiki with > instructions on how to maintain their deployed solr, What a terrifyingly imaginative example haha! Thanks all for the pointers and ideas! Gus - I definitely see the value in making better use of the servlet/filter abstract

Re: v2 API "Broader Changes" and Next Steps

On Sat, Jul 23, 2022 at 1:38 PM Shawn Heisey wrote: > On 7/23/2022 9:41 AM, Gus Heck wrote: > > 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

Re: v2 API "Broader Changes" and Next Steps

Really happy to see everyone's interest in supporting beginning users. I often feel protecting them is one really important aspect of supporting them. There is a mechanism for disabling the Admin API by default. In SOLR-14014 I added a flag for th

Re: v2 API "Broader Changes" and Next Steps

On 7/23/2022 9:41 AM, Gus Heck wrote: 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). If the only way to make certain things happen with a GE

Re: v2 API "Broader Changes" and Next Steps

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 o

Re: v2 API "Broader Changes" and Next Steps

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 th

Re: v2 API "Broader Changes" and Next Steps

On Thu, Jul 14, 2022 at 4:31 PM Jason Gerlowski 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 movin

Re: v2 API "Broader Changes" and Next Steps

Hey, thanks for chiming in David, Houston, Eric! I'm glad to get a few affirmations on the general direction/approach of the design. Some responses (mostly agreement) in-line. > I strongly prefer to move our functionality to implement the new API as at > its core/directly, and then have v1 be a

Re: v2 API "Broader Changes" and Next Steps

I did look over it twice now, here & there. Boy, there is a big API surface area to Solr! Thanks for working on this huge task Jason! 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. From an implementation perspective

Re: v2 API "Broader Changes" and Next Steps

As far as CORS goes, I think you are right technically…. It’s it’s own thing. Maybe I think of it as part of API from the perspective that supporting CORS makes it easier to integrate with the API from other systems. Kind of like supporting Swagger etc… > On Jul 14, 2022, at 11:35 AM, H

Re: v2 API "Broader Changes" and Next Steps

I have added some comments to the API spreadsheet, but really like the direction. Thanks for putting all of this together, it couldn't have been easy! - Houston On Thu, Jul 14, 2022 at 7:00 AM Jason Gerlowski wrote: > Hey all, > > Wanted to give another "plug" to the spreadsheet of proposed v2

Re: v2 API "Broader Changes" and Next Steps

Hey all, Wanted to give another "plug" to the spreadsheet of proposed v2 API changes, in case folks missed it the first time around. Please take a look and review whenever you get a chance! https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing > Lo

Re: v2 API "Broader Changes" and Next Steps

Love to see CORS support added ;-) > On Jul 6, 2022, at 9:45 AM, Jason Gerlowski wrote: > >> [Jan] I think it is better for the project to evolve and fix this > > Glad to hear it; sorry for the confusion if I misunderstood your concerns! > > Well in that case it sounds like there's general su

Re: v2 API "Broader Changes" and Next Steps

> [Jan] I think it is better for the project to evolve and fix this Glad to hear it; sorry for the confusion if I misunderstood your concerns! Well in that case it sounds like there's general support for the idea of broader changes to the v2 API, and no categorical objections (albeit a few concer

Re: v2 API "Broader Changes" and Next Steps

> I'd love to find a way to > address your concerns and still evolve v2 without backcompat, if we > can. I just wanted to highlight that some users may be using v2 without realizing it was experimental due to the back-and-forth communication we have had on this. Personally I think it is better fo

Re: v2 API "Broader Changes" and Next Steps

> I hope I am not misunderstood ... I absolutely think we should fully embrace > proper HTTP verb usage in v2 and document it extensively Oh. I was misunderstanding you apparently then. Great! My mistake on the misunderstanding; I appreciate the clarification. I do think that the "Swagger UI"

Re: v2 API "Broader Changes" and Next Steps

On 6/17/22 18:21, Noble Paul wrote: 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 discus

Re: v2 API "Broader Changes" and Next Steps

@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 m

Re: v2 API "Broader Changes" and Next Steps

I really appreciate the perspective you bring Shawn on helping users... we should think about how to make it easy for a user to run a command... maybe an explicit admin UI for running arbitrary commands int he same way we use the browser??? On Fri, Jun 17, 2022 at 1:35 PM Shawn Heisey wrote: > O

Re: v2 API "Broader Changes" and Next Steps

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 uni

Re: v2 API "Broader Changes" and Next Steps

Hey all, Thanks for the quick responses! Overall it sounds like no one objects to the idea of broader changes necessarily, but that there are some concerns about the timing/mechanics (backcompat, target release, etc.) and specific API design (use of HTTP verbs, "URL-bar" friendliness, etc). Hope

Re: v2 API "Broader Changes" and Next Steps

@Shawn So, if we move towards an HTTP POST , PUT or DELETE based commands we will never be able to send a link to others over text format because they work only on HTTP GET. I think this is an artificial limitation that we are going to impose on anyone designing an API standard and against the wid

Re: v2 API "Broader Changes" and Next Steps

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

Re: v2 API "Broader Changes" and Next Steps

The direction that we are headed for how you interact w Solr is via the admin UI. I am thinking of the security and schema designer additions for example. And some outstanding pr’s to add support for paramsets to the Admin UI. Personally I always found using the browser to be very clunky and da

Re: v2 API "Broader Changes" and Next Steps

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

Re: v2 API "Broader Changes" and Next Steps

V2 has existed since v6.5 and has been documented in ref guide evner since. In 7.0 release announcement we said: The new v2 API, exposed at /api/ and also supported via SolrJ, is now the preferred API, but /solr/ continues to work. We have been showing v2 api commands in tabs for e.g. config ap

Re: v2 API "Broader Changes" and Next Steps

I suspect that #2 will inspire #1, once we start trying to use it everywhere in SolrJ and other areas we’ll see patterns and antipatterns emerge and guide us on what the API should be. On Thu, Jun 16, 2022 at 6:05 AM Jason Gerlowski wrote: > Hi all, > > I've been working over the last few months

Re: v2 API "Broader Changes" and Next Steps

I don’t have the link, but I think we agree that v2 *could* evolve, hence the whole experimental thing. I worry that the efforts of maintaining three versions of the api will stall us. Especially if the changes we want to make aren’t wholesale changes. Now if we introduced a graphql based api

Re: v2 API "Broader Changes" and Next Steps

HI, Thanks for having the guts to start such a journey! V2 has been around for several major releases and documented (it's in v6.6 guide https://solr.apache.org/guide/6_6/v2-api.html ) long enough that we must assume a certain user base already. T

Re: v2 API "Broader Changes" and Next Steps

Thanks Jason for spearheading this effort. I'll be biased because I built it. So, I refrain from a vote. However, I shall contribute constructively to the discussion On Thu, Jun 16, 2022 at 9:05 PM Jason Gerlowski wrote: > Hi all, > > I've been working over the last few months to get our "v2"

v2 API "Broader Changes" and Next Steps

Hi all, I've been working over the last few months to get our "v2" API into shape to eventually replace (and allow us to sunset) v1. At a high level the two biggest next-steps are to (1) make whatever changes we'd like to the v2 endpoints while they're still "experimental", and then (2) start usi