I have an issue with Get Request (others have reported similar issues): it responds with a json body when request is successful, but responds with a blob when not. The way I solved follows this pattern:
I like the idea. I am also using different workarounds like filtering for the result using the status column as shown in the screenshot.
But receiving an empty JSON would only work well if the response (in case of success) is a JSON type. Some times the response is just a plain text or an XML and it is hard to know that in advance.
You could save yourself one node by using our ‘If switch (Flow variable value)’ node
Otherwise, as @temesgen-dadi says, without knowing what sort of response a failure is going to give it’s difficult to be able to handle otherwise in a generic node such as the GET Request
first of all, thanks for posting and bringing this up.
I think checking for the HTTP status code and using an IF Switch or Row Filter is the most reasonable way to go. Of course, it always costs some time to add additional nodes and it would be great if the node could handle all this.
But consider this: an empty JSON/XML/binary is semantically different from no response. The former indicates a response absent of information, the latter that no response could be obtained.
Which value you fall back to and whether you do this at all depends on the specific use case. As such, I currently think that handling that explicitly in your workflow is the most adequate way to implement this.
The next idea that comes to mind is that instead of trying to find a reasonable fallback value, we output a missing value and let the user fixate the type of the response column. This would allow such loops as in the original post – but you would still need to check for the missing value. You do not gain anything in this case since you might as well check for the HTTP status, which even more precisely describes the status of your request.