HTTP requests

[Rob Br]

Hi,

The picture probably makes clear what I mean with the following question:
Is it possible to receive an GET request (from a different origin/JSONP), that is then processed, and during the processing some additional POST requests are fired to another server which response needs to be appended to the arguments of the padded JSON function?

Of course I could just use another request from within the callback to check for the results of the POST request, but I would prefer to do it in one step.

Appreciate any suggestions! Thanks

[Rob Br]

Some additional info.. When I wire it like this, without the function node on the end everything works without errors. However, when the function node is attached (even when it is just returning an empty object) it is not working anymore. See screenshot attached.

[steve rickus]

Without seeing your javascript code in that final function node, it's hard to say what the problem is. However, enough of us have made similar mistakes -- so my guess is that you are not retaining the original msg.res object from the http in node at the start of your flow. Without that, your http response node at the end cannot properly reply to whatever client made the initial request...

However, it does look like you saved it as msg.ores, so perhaps there is some other node messing with your msg structure. If you post you flow as JSON (not a picture), you'll get some better advice, no doubt.

--

Steve

[Rob Br]

Thanks for your reply!

The reason for saving the res attribute as 'ores' was that I thought that the other requests might interfere with this property.

The final function node would then create an object like so (that is all code in this node):

return {res: msg.ores, payload: "featureUpdateResult('test')"};

Which flows into the response node, but that doesn't seem to work however.

Op donderdag 19 april 2018 18:18:48 UTC+2 schreef steve rickus:

[steve rickus]

Right, that is a valid approach -- but i think the issue is that you are creating a new msg object, instead of reusing the incoming msg. That is not usually a recommended practice, because it loses certain internal fields that upstream nodes may be settings (e.g. parts, topic, _msgid)

I might be worth trying to re-use the existing msg, and just over-writing the res  and payload fields:

msg.res = msg.ores;
delete msg.ores;
msg.payload = "featureUpdateResult('test')";
return msg;

Also, I'm not sure why you would be returning the payload as a string that looks like a function call... is there a javascript function called featureUpdateResult() that you are trying to invoke, returning the contents as the payload? Or does the client handle that somehow? What response content-type is supposed to be returned from this http api endpoint?

--

Steve

[Rob Br]

I'm now reusing the original msg object (already tried that earlier without success).

This causes the second-last request node to hang on 'requesting'.

The final node now contains the code you suggested.

I do have to mention that in earlier function nodes I change the header for the POST requests, could that be causing the problem?

Indeed what I am returning to the client should in the end be a function call with JSON as argument (actually some metadata of spatial features modified in the POST request) like so:

   [ {

        "attributes": {

            "Name": "Lichtmast 1",

            "Status": "OK",

            "OBJECTID": "2"

        }

    }

];

So the string is just for testing purposes here.

Op vrijdag 20 april 2018 15:07:34 UTC+2 schreef steve rickus:

[Rob Br]

Problem solved.

I was thinking too difficult with saving the res as ores and restoring it back to res in the end.

Just don't mess with these attributes at all and in the end it just worked!

So the response is now a function call padded with JSON obtained through the POST request to a third server.

So I can now confirm such a construction is possible with Node-Red.