For what ever reason its seems like that sending a GET Request with Content-Type set to Application/Json and feeding it a jsnoized None leads to a null being attached to the request url.
I am catching now if the data is None before jsnosing it, but yeah. Took me a while to find,.
If you’re trying to get the JSON dictionary contents into the GET query string then you can just pass the data var:
op('webclient2').request('localhost:9981', 'GET', header=header, data=data)
Im not trying to do that, this is why this is why it threw me off.
I created one client for all cases (for a specific api) with different methods. This requires me to send the content as application/json and json-dumped dictionaries in the bodie because when using the regular url-encodec content type I just get garbage when sending text-content with newlines in the data dictionarie (maybe thats the bug?).
So to not have to catch all cases for different request methods im just not converting None to a json string if needed.
Or do I understand it right that the webclientDAT will append all content in the dataDict as qeuryParameters per default to request when sending a get-request? Don’t know how I feel about that to be honest. Data should be body (and if we cannot send the body because of option/get etc then we should just not send it and not try to append it to the URL as query parameters (because this does not play well when I already take care of the query parameters myself.)
when using the regular url-encodec content type I just get garbage when sending text-content with newlines in the data dictionarie (maybe thats the bug?).
I’ll test here to see if I can reproduce. We do do some url encoding on our side (in particular for building up query parameters) so maybe the text is being url encoded twice.
Or do I understand it right that the webclientDAT will append all content in the dataDict as qeuryParameters per default to request when sending a get-request?
Yeah that’s what’s happening here.
Data should be body (and if we cannot send the body because of option/get etc then we should just not send it and not try to append it to the URL as query parameters (because this does not play well when I already take care of the query parameters myself.)
Noted. I’ll see how I can resolve this. Might need a toggle on the web client DAT to switch between the two behaviours.
Hmmm, I understand. That makes sense in the context of being able simply define the values as the inputDAT (and actually kinda neat). I can see that behavior being a good idea for the completly nodebase workflow. But for the programmatic request() approach I could see maybe splitting data in this case up into body and params to a keep them from being mixed up and still being able to use that workflow when I’m using post-requests. Because now I kinda have to accomidate for two cases and keep track to not put any data into a get-requests (as I have to define the query params anyway by hand for posts)
Good suggestion. Splitting it up into body and query parameter keywords would make it more explicit and also be useful to other request methods.
For a DAT workflow I think it can be kept as is.