Forum Documentation Showcase Pricing Learn more

We Really Need a GET Method for Workflow APIs

My vacation rental tools app makes embeddable/iFrame-able widgets. I had a little brainstorm today and got all excited about adding support for the oEmbed standard and getting them set up with embed.ly.

After doing a bunch of work to make ensure they’re compatible with Embed.ly’s restrictions, and started setting up and testing some API Workflow endpoints, I remembered that…

Even though you can now create API Workflow endpoints that only take parameters passed in the URL (that is, they require no BODY content), Bubble throws a 405 error if you try the GET method on that endpoint.

Like, here’s URL on my Bubble app that would spit back (I think…) some JSON representing a (close to proper) oEmbed response:

https://grupz.com/api/1.1/wf/oembed?url=https://grupz.com/bookwidget_embed_280/1533598513737x940983987061391400

… Except that Bubble throws a 405 error:

{"statusCode":405,"body":{"status":"ERROR","message":"Wrong method. Should be a post"},"args":{"bubble_code":"1537917189069x708313714247196900"}}

But of course, there’s no reason for Bubble to do this anymore.

If an API Workflow has no required BODY parameters, that workflow should allow both GET and POST methods.

Pretty please, Bubble gods? The above is a real-world example of a situation where one needs a POST-like workflow (i.e., one that spits back a rather complex, custom response, not an object from the database) in response to a GET request.

Seems like this should be an easy change because it’s clear that Bubble is clearly just evaluating, “Oh, you’re hitting the wf endpoint with a method that is not POST. Here’s a 405 error.”

Please let a GET trigger the workflow. Thank you!

10 Likes

I’m no expert on how easy of an update this would be for the Bubble gods or if it makes sense on the back-end to allow this, but I’m going to +1 it anyway. I’ve run into API roadblocks before specifically because of unsupported method.

What would be really interesting too is that you could actually retrieve app data by calling an endpoint with GET and use “Return data from API” to return values, and you can use query parameters sent to the endpoint as a way to constrain a search. I’ve been working with https://pdfgeneratorapi.com/ to retrieve data from an app to fill a PDF template, but they only use GET calls for endpoints you give them.

It would be so so easy to call an API endpoint to return the exact values I want, but the method cuts it off.

Yes, I know we have Data API where we can constraint a lookup with url encoded constraints, and that’s what I’m using currently, but the url encoding part just makes the whole process tricky when I’m trying to do everything dynamically. It seems like if we could call an endpoint with GET, it could provide an “easier” way to retrieve app data because the parameter keys can be anything and you don’t have to encode.

Maybe I’m missing something fundamental, but those are my thoughts.

6 Likes

In attempting to work around this issue (outside of Bubble), I’ve found that one can use Amazon API Gateway to transform one type of method to another. It’s kind of a totally stupid waste of time to have to do this, but you can. Here’s a screenshot: This GET fired at Amazon API Gateway triggers a POST in my Bubble app and passes the response data back:

Now, that’s not the ONLY reason I started looking into AAPIG… The OTHER blocking issue with (for example) setting up proper oEmbed responses is that Bubble gives us no ability to return HTTP STATUS CODES. oEmbed spec requires one’s API to return certain specific status codes for certain situations (like 501 if the thing the consuming service has requested to embed is not available in the format that the consumer wants).

AAPIG can also transform one type of status code into another, but only based on the pre-existence of a status code (as far as I can tell). So consider the following:

A Bubble workflow API endpoint will really only ever return 2 status codes that one has control over: 200 (success – and of course one can force Bubble to ALWAYS return 200) and 400 (if there’s an “Only when” condition on the API does not pass or when a required parm is missing).

But I need to be able to differentiate on 4 different status conditions. I’ve tried all sorts of hacky stuff (like, I thought it might be possible to remap status codes based on body/payload content – that would actually be totally rad – but if there’s a way to do that it’s not up in the UI but within the body content remapping features, which — get this – are scripted using Apache’s Velocity Template Language (“VTL”).

WTF knows VTL and wants to be bothered with looking at the crappy Apache VTL reference and Amazon’s very very very detailed but entirely too wordy “tutorials”.

Anyway, long story short: BUBBLE gets to throw around 405 errors (for no good reason), but Bubble developers cannot throw around ANY errors (even when there’s a reason). Sigh.

1 Like

+1 for this.
The current limit of 50 rows returned by the “Return data from API" makes it unusable in many scenarios.

The sad part is that I’ve seen a lot of people using it without even being aware that there is limit of 50 rows (even though it’s stated in the manual).

3 Likes

In fairness to the Data API:

That sort of limitation is very common though. Basically, the output of the data API is paginated. (I kinda feel that the Reference explains this the wrong way — it calls it a limit and then explains how to paginate. Output is just always paginated is more the point.)

As for using the capabilities of the workflow API as the result of a GET, note that using Amazon API Gateway as I describe above makes this entirely possible. (And easy.)

I haven’t tested what happens with very large payloads though (do they truncate at some point, perhaps based on time limit?)…

@keith, i think you’re missing the point @romanmg and I raised about the “Return data from API”.
This is not the Data API but rather the Workflow API.

There is no pagination here when getting data using the “Return data from API” action.
Below is what the reference manual states:

In the case of the Workflow API, we limit the size of lists to 50 entries. For a full list of data, please use the Data API that handles pagination.

So there is a difference between getting data from the Data API and getting data from the Workflow API.

I’m not sure if this will still address the 50 entries limit?

Hey @seanhoots - well, I sorta glossed that you were talking about “Return data from” limits as my mind immediately went to Data API/paging.

But related to what you’re saying: They way to dump large (well larger) quantities of data OUT of Bubble is to stand up an external API that can consume that data and POST it via the API Connector.

Example: “calendar.ics” here is a microservice running on webtask.io that I set up. It takes individual event information, creates an iCalendar .ics file and passes that file back to the requestor (Bubble in this case).

The lists here (of start dates, end dates and summaries) can number in the hundreds and the entire operation takes just a couple seconds for the entire round trip:

No, it wouldn’t. But see my other reply.

+1 for this discussion as well as the points raised by @romanmg.

From more of a business standpoint, I am curious about you wanting to use embed.ly. I am not familiar with it, but I do have an app where my clients can embed some basic parts of it with on their websites with an iFrame and I was actually just thinking of improving the embeddable parts soon.

So what is the difference between using embed.ly and just providing a snippet of code for an iFrame?

If this strays too far from the topic of the post shoot me a DM

Hey @gf_wolfer, what you’re asking is right on topic. Rather than write on at length here about the relationship between oEmbed standard and embed.ly and why it’s important and useful today, I’m going to instead point you to THIS really terrific article which explains as well as I could (and also introduces you to all the necessary technical details):

https://blog.ycombinator.com/how-to-build-an-oembed-integration-for-your-startup-and-why-its-necessary/

So in my app, my interface does the same thing that you describe. You can configure/customize widget and I serve you up the iFrame code you need to embed. And of course, there’s a “copy to clipboard” button to make that easy. And, I also show you the link to that object on its own page, right?

SO while it is not HARD for a user to take the line or lines of embed code and put them somewhere, the world has MOVED ON from this kind of approach. What is more common now is for a thing that supports embedding to use embed.ly (or sometimes the page’s discoverable oEmbed information) to auto-fetch the necessary embed code and do it FOR YOU.

You see this for example in Squarespace editor. When i was testing my iFrames there, I noticed that you put down an Embed block and it says, “Hey, past the URL of the thing you’re trying to embed and we’ll give it a shot.” And I was like, “Huh, I wonder if that works for MY page?”

Well, of course it doesn’t as I didn’t understand how the auto-embed thing worked. So what squarespace does then is lets you paste in explicit iFrame code, right?

But wouldn’t it just be SO much better if I could tell my users: Hey, I give you the iFrame code here so you can embed this anywhere, but most places on the web you can actually just paste the URL to your calendar page (or booking widget page) and they will auto-magically embed!

That’s what oEmbed / embed.ly can do for you. But as I note there are several blocking issues that can keep you from creating a fully compliant oEmbed API for your app in pure vanilla Bubble.

I’m still obviously working out the minimal easy approach to accomplishing that. However, once I figure it out (meaning that I’ve created an API endpoint that successfully passes embed.ly validation) I will share some info on that here.

Best,
K

2 Likes

Possibly interesting update on this. Behavior seems to be changing a bit. Today, calling a workflow API call as a GET (like putting the address in the browser), returns a 401 “unrecognized authorization type” rather than giving the 405 “wrong method” error.

Trying https://grupz.com/api/1.1/wf/oembed as GET gives:

{“statusCode”:400,“message”:“Unrecognized authorization type”,“args”:{“bubble_code”:“1537993370605x584895459469407760”}}

Hmm… is change a comin’?

@romanmg Off topic: I am currently using PDFotter for pdf generation based on filled in fields. Works great with the API connector, also less expensive than pdfgeneratorapi.com. Probably worth checking out.

1 Like

I think ya posted this reply to the wrong topic, but hey I didn’t know about PDF Otter - interesting. :stuck_out_tongue:

@keith it was a reply on @romanmg comment :slight_smile:

Thanks for the tip!

Thanks for the detail!
For my own app, I’ve noticed the iFrame not being served up on my client’s Squarespace website with Safari mobile, wonder if this could help solve that. At the very least sounds easier for my non-techy clients to paste embeds

Would be great to see if you get things working with this

Well, this would not help with your Squarespace/iOS Safari issue. To debug that you need to examine that page.

What oEmbed APIs do is translate: “here is the URL of a thing I’d like to embed and here’s how I’d like to embed it” into “OK, here is are is the iFrame code you need” or “sorry, we don’t let you embed that and here’s why.”

But yes I’d like to get this working. At present, I’m seeing if I can get something like Amazon API Gateway to translate responses that I can put in the body of Bubble’s api workflow response into the right status codes needed in response to an oEmbed check. (I keep hitting little issues in doing that. Have also looked at Tyk - another API Gateway. It may be that there is NOT an easily available gateway that can do exactly what is needed here. I won’t belabor the details, but it’s starting to look like it may not be possible.)

The best fix would be significant enhancements to API Workflows in Bubble. The main missing thing is an action to return a specified HTTP status code as well as a custom body.

Might be that one would just have to do it the old fashioned way and write some code on another microservice like webtask or something. I’m not sure it’s worth the effort.

Basically, the idea I had is something that should be easy, but is not as certain requirements are missing from the Bubble feature set in this particular case.

it’s a really cool thing to have learned about, though…

+1 for this!

+1 for GET Method