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:
… 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!