I am so grateful for this announcement. I am not able to give feedback because I am still onboarding this entire idea, but I will definitely follow the topic. My app will not become an app If I cant figure this API connector out, which is a topic of its own. I do see one thing different aside from placement and its the little word “parsed”. I didn’t see it in the plugin area but I have a feeling it has something to do with my issue. I will stop here, I don’t want to take from the announcement, its sounds good. I’ll be in the help needed area when I find out how to use or request it ; )
So previously when we initialized a call, it would automatically sanitize the results for security. I noticed we can still see the results now. Is it more secure now somehow? Or do we have to go back and sanitize the results for ourselves again? @nick.carroll It looks like it still might be auto-auto sanitizing but somehow we can still see the data safely? 
Ok. In the interest of making the UI more approachable and less confusing - especially for new and/or nontechnical users - I strongly suggest rethinking the UI for specifying body content. Consider, for example, the following configuration for a POST request…
Guess what gets sent as the body. Absolutely nothing. It’s empty. Why? Because the two indicated regions represent entirely separate and distinct, and importantly, mutually exclusive ways of specifying the call’s request body. But the UI makes that about as clear as Missouri River water. (In case you’re wondering, the Missouri River in the US is nicknamed the “Big Muddy”.)
If the Queryst. option is enabled for the first three params, then the call gets sent as expected - i.e. 3 query params plus a JSON body with params 4, 5, and 6. Similarly, if the JSON content is deleted from the second input method, then the call gets sent as JSON with params 1, 2, and 3.
Basically, if there’s any body content defined in both sections, Bubble sends an empty body. But more importantly, it provides no feedback that anything is wrong. At a bare minimum, some red text should appear informing the user of the issue.
Each of the input methods has some advantages and disadvantages. The first is fine for flat JSON structures with simple string values. Bubble automatically formats the values as “JSON safe” - i.e. runs the values through JavaScript’s JSON.stringify() method before sending. The downside is that there’s no way to send more complex JSON structures or anything but string values, such as a numbers or booleans (true/false).
The second method is much more versatile and powerful. You can create nested JSON structures, including dynamic lists, as well as send non-string values. But of course, it takes more time to set up. (If you’re relatively new to the API Connector, you might benefit from this revelation I had a few years ago, after I’d already been using Bubble for several years.)
Anyway, this is one aspect of the UI that could benefit from a redesign.
1 Like