I am using (trying to use) the standard http-request node to query a website. Unfortunately, the site's answer does not include the original request information. Since there may be several requests running, how can I associate the request and response correctly?
Maybe I am just using it wrong, or I don't get it right? In a classical programming environment handles would be used for this.
2nd, the request is derived from another processing task, it is used to augment existing information. I assume I have to use the context store to temporarily store information until the request is finished by a response?
(Background: I request a list of place names in a regular interval via HTTP – that's easy. In order to show them on a map, I need to request a reverse geocoding service for each place to get coordinates. Caching places that were already resolved is also desirable; using the (persistent) context store would provide for that.)
The http-request node will output the same msg that was passed into it.
e.g. if you pass in a msg object that looks like:
{
topic: "foo",
payload:{
name: "Ben"
},
counter: 99
}
And the http-request node is set to pass the msg.payload as arguments to the request URL, (assuming the http server return "Hello [name]") the output msg object will look like:
{
topic: "foo",
payload:"Hello Ben",
counter: 99
}
As you can see the topic and counter fields have been left intact. You can use this approach to attach what ever meta data you want to the msg as it passes through the flow. If you have state information that is not directly related to a give msg, then the context is the right place to store it.
All well behaved nodes should always output an updated version of the input msg.