I recently discovered something about the API Connector that others might find useful. In a nutshell, when an API call is configured with the “Use as” field set to Action instead of Data, the response does not get cached. So there’s more to that setting than just where/how in the editor UI the data is specified.
Over the years, I’ve seen forum posts describing various cache busting strategies when dealing with API responses. What this “discovery” suggests, though, is that such strategies should be unnecessary if the call is simply set up as an action.
Of course, that means using the Display data in a group/popup action from a workflow instead of referencing the API data via an expression in a Data source field directly.
Anyway, I stumbled upon this recently, and the behavior actually makes some sense. However, I didn’t dig too deeply into it; so it would be nice if someone else could corroborate this finding.
Yes, if you use a data API call on a page, it will only update on a given page load when the input expressions change and will only re-request as needed (a bit like how, for example, a dynamic search will only update when its constraints change, with the caveat that it’ll also update in real-time if the results change).
An action is executed every time in every workflow, as it is intended to do something so naturally will always run.
Nothing new here. However, a moment ago (more than 1 year I think) when setting API to “action” this was not creating a “type” of this api call and was not available, for exemple, in Schedule on a list options. This is not a problem anymore.
I’ve been dealing lately with GET requests primarily, and it makes perfect sense in that case. Since the parameters are part of the URL, if the URL changes, then it’s a “new” resource being fetched.
Are you saying, though, that it’s true regardless of the HTTP verb? I didn’t really examine that specifically.
I don’t think the verb change anything on Bubble side.
Technically, a GET should be a DATA type while all other should be ACTION. However, some API “search” functions will use POST request (so you can provide a JSON for example, something that is not recommened when using GET request). For me, a search should be a DATA call. Each time you fetch data should be DATA and when you modify or delete data on server, you should use ACTION. Again… this is technically because there’s nothing wrong really to use action or data. Just that they won’t be available the same way. I think Bubble should just remove that and let user use all API call as action and data.
Thanks, @Jici. Yes, I’m familiar with the HTTP spec, and generally speaking, I agree with you.
Way back when the API Connector was first developed, I suspect they tried to abstract away some detail to make it easier to use for the less tech savvy. However, it has “evolved” to a point where it can be cumbersome and confusing to use at times; and I think everyone would benefit from a revamped UI. Why should anyone have to “learn” the API Connector’s quirks and idiosyncrasies or work around its bugs - especially when the entire goal is software interoperability.
There are some security advantages to using actions too, as dynamic values inside data calls can often be adjusted or executed arbitrarily, whereas in an action it can strictly only be executed through the context of a workflow.
