Feature Request: Support method 'QUERY'

[Polo2]

Hi Alberto,

As already mentioned by my teammates from PR #19 and #22 , thanks a lot for the work you do here, this lib is very useful for us (generate great visual curl request for an Api Explorer).

We are working on support of OpenAPI 3.2, where new HTTP method 'query' is available, as defined in the most recent IETF draft draft-ietf-httpbis-safe-method-w-body-08

Do you think it would be possible to support this new verb in method parameter

In https://github.com/albertodeago/curl-generator/blob/master/src/main.ts#L52 if I get it well?

Thanks in advance for your answer,

Polo

[albertodeago]

Hey @Polo2, thanks for reaching out!

Sure, I don't see why we shouldn't support query as well...
Is it sufficient to add if it as a possible 'method', or does it requires something more?

[Polo2]

Hey @Polo2, thanks for reaching out!

Sure, I don't see why we shouldn't support query as well... Is it sufficient to add if it as a possible 'method', or does it requires something more?

I didn't tested, but yes, I'm quite sure it should be enough to include 'query' in this list.

But I'm also struggling with a similar issue from OpenAPI 3.2, looks like other verbs may be defined:
'options', 'copy', 'trace', 'head'... and even custom verbs with additionalOperations
(cf OpenAPI specification about Operation)

Maybe CurlRequest could accept any method?
or an optional parameter to skip this validation?

WDYT?

[albertodeago]

🤔
Surely we're missing some options (the ones you mentioned options, head, ...) because it never occurred to me that I needed them.

I prefer leaving the type as narrow as possible, so I'm going to add 'options', 'copy', 'trace', 'head' AND let's add also 'query' if I'm not sure it's official yet (but still, not going to cause any harm)

Can I proceed this way?

[albertodeago]

WDYT of #26 ?

[Polo2]

thank you very much for your responsiveness, it indeed seems relevant to support these 'official' methods.

I don’t have a strong opinion on the possibility of supporting any verb, I indeed understand the desire to keep a validation for the moment.

[albertodeago]

Should be done with v0.5.0

[Polo2]

Works like a charm, thanks 🙇

[paulRbr]

Hi @albertodeago,

one small argument to pass in the method string «transparently» (without the curl-generator doing any filter) is the man page of curl:

       -X, --request <method>
              Change the method to use when starting the transfer.

              curl passes on the verbatim string you give it in the request without any filter or other safe guards. That includes white space and control characters.

Curl doesn't do anykind of filtering or safe guarding, so I don't think the generator should do this validation. Maybe we can add an option to disable the method validation?

Thanks!

[albertodeago]

Hey @paulRbr, probably I'm a bit slow brain today (so apologise in advance 😬 ), but I didn't get it, can you explain it better / provide an example of the problem or what you intended?

[albertodeago]

Ah I see, I think I got it, you are saying "given that CURL doesn't validate the method, what is the generator doing any kind of validation"
right?

[paulRbr]

Sorry for not being clear, yes that was indeed my point: aligning the validation of curl with those of the generator.

However, I understand the generator wants to have a validator (to avoid typos, bad user input, etc...). That's why I suggest to add a new option to the lib something like noValidation: true which would bypass this kind of validation and just send the user inputs verbatim to the generated curl command.

What do you think about it?

[albertodeago]

I understand your point. While I'm not against it, I'd like to ask you if there is a use-case at the moment, or if it's just to make it more extensible for the future.

What I could do, that I believe is a bit of best of both worlds, is that I could set methods in TS in a way that the editor will provide you autocomplete capability (e.g. you type G and it suggest you GET, or you just cmd+space and it provide all the possible methods listed) BUT it also enable you to just write whatever you want and it won't complain (e.g. you type G it suggest GET via autocomplete, but you then write GET_OFF_DUDE and TS won't complain)
I'd prefer this over the noValidation: true.

Said so, if it's just for "possible future values", I'm more inclined to keep it as it is now for the time being, and maybe next time implement what I just wrote