Does anyone know if there is a way to include API request keys ONLY when they are not empty?
I have a PATCH API with many parameters that permit NULL as a valid value. PATCH APIs typically work by changing only values that are provided in the request - but bubble passes ALL parameters, even if all are empty. This effectively means that bubble is not complying with the expected usage patterns for a PATCH API.
My backend infrastructure is primarily Xano, so I am also using my own forked version of the Xano Connector plugin, thus could theoretically use that for making these API calls (as it fully supports this) - but I would need to create a server-side action to replace the API connector-based call, since I still need these actions to occur as part of a workflow (to synchronously handle response errors and bubble data changes etc.). As such, I would still rather use the API connector natively, as opposed to working on my own solution. Either that, or send through data for every parameter, even if they aren’t changed… which is hugely wasteful and potentially introduces data problems or corruption.
You can have the whole API connector body wrapped in <> and when running the workflow, enter valid json for the keys you need.
That’s a good point… hadn’t actually thought of that. Not going to be pretty (there’s about 20 parameters for this particular API), but doable.
sigh if only bubble followed standards on the API connector. Just another issue to add to the list of numerous other issues with that plugin…
To enhance this, it would probably be fairly easy to build a plugin action that takes up to N number of key-value pairs and formats them as payload (if value is not empty). It can be used directly in the API body and can persist around so it doesn’t require a lot of maintenance.
Agree, it would be fairly easy (there are already client-side versions in my Xano plugin, so it’s definitely doable) - the main annoyance is that the bubble plugins don’t have dynamic properties, so it would pretty much be no different from the solution you suggested above - just passing a JSON slab of text to the connector. You could always pass the parameters as a list - but the effort building that list in the first place is probably just as annoying as a slab of JSON…
Anyway, the “slab of JSON” approach works perfectly, but it’s going to be truly chaotic evil to debug this if I ever need to troubleshoot it (almost certain!):
I imagine a plugin action that has 20 inputs for keys and 20 inputs for values (for example) and it output already formatted json which you can reference in the body of the call. Sounds manageable
