We Really Need a GET Method for Workflow APIs

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.

4 Likes