A URL to call/execute a node red flow?

General
1

Hi

is it possible to call/execute a node flow via an simple http request /url from any standard browser ?

I was looking in here http://nodered.org/docs/api/admin/methods/ but could not see anything specific, I would assume it starts with the normal url http://localhost:1880/ but after than i’m not sure..

2

look at the http-in node ( which must end with a http-out node)

3

There are lots of recipes for the HTTP In node in the cookbook - https://cookbook.nodered.org/http/

4

Hi,

Thanks for responding, following the links, I’m sorry to say I’m not clear how this would need to be set up.

How do I create the url, which can then be called from any browser, on any device on the same network to run a particular flow ?

when I look at the flow I would like to remotely run, its seems to be given this number/ref = [9e5667d9.c17f1] when executed.

Sorry if I am confusin matters.

5

Lets take https://cookbook.nodered.org/http/create-an-http-endpoint as an example.

It shows you how to create an HTTP In flow configured with a path of /hello. If you access Node-RED at http://localhost:1880, then you can trigger the HTTP In node by making an HTTP request in http://localhost:1880/hello.

In these examples, 'localhost' refers to the device running Node-RED - and would only work if you typed that into a browser on that same machine.

To access it from other devices on the same network, you would replace localhost with the ip address of the machine.

6

Many Thanks @knolleary

Ok, I have followed the /hello example, and get the response page up - but how do I update the flow so when that /hello url is called, it invokes/triggers a particular flow to run/execute ?

7

Instead of showing the page just send a message to your flow to do its thing.

8

Actually that should be as well as showing the page, obviously the browser has to show something when the user goes to that page.
Are you sure you have thought this through fully though, what exactly do you want to happen from the users point of view?

9

The rational is more about having the ability for users, or other systems to invoke a flow, by simply calling a url.

That http/url approach seemed the most logical way to do it?

10

Remember that if you are out on the internet then you may well get random hits on your url from bots tralling the internet, so your flow could be triggered at any time.
Also if a user refreshes the page then it will hit it again, and conversely there is the risk that going there in the browser may not hit it at all, the browser may serve it to the user from its cache. There are ways of mitigating that problem though.
Generally it is considered a bad idea to use a url GET to trigger an action, for all the above reasons. You should really use a POST so it cannot be done accidentally. Or some completely different way using Telegram or MQTT or similar.

11

well a simple way would be to add a wire from that http in node you have to the rest of your flow... then when it is "browsed to" it will trigger the flow... - but as already pointed out if you want something back to the user it MUST go back via the http response node.

12

Thanks all, great points to consider .

As all this is being done on a private network, the url would not be exposed to anything directly from the network.

@colin, regarding your example about dong a POST bing better - how would that work with a flow ? Would that require someone to submit something each time so that the flow to be executed ?

13

I love IBM and their CookBooks ! (Used to Work in Australia for IBM a long time ago !)

Craig

14

I think you mean Redbooks :wink:
www.redbooks.ibm.com

1 Like
15

Can you explain exactly what you are expecting the user to do and what should happen in his browser when this it to happen? I still don't fully understand the use case.

16

Hi @colin, the use case is still the same as above, to provide a way to execute a flow via a url.

My comment was in response to your, as I was curious how POST would work (what would the user do differently), compared to GET as you had said that was a bad idea. I’m not familiar with the differences.

17

That does not explain everything. How is the user going to hit the url and what do you want to happen in the browser when he does that? That information is crucial in determining fully what needs to be done.

18

Used to love those too! Full of useful info.

Going back even further, we had massive racks of IBM manuals covering all aspects of the IBM mainframes in use when I started in IT. One of my early roles as an intern was to take all of the outstanding updates and apply them to the ring binders that were the manuals of the time. I learned so much that summer! The team who were meant to do that stuff (the tech support guys) were amazed that I actually wanted to read that stuff :slight_smile:

OK, nostalgia mode off, back to normal programming!

1 Like
19

The user can execute the url from any application that makes it a hyperlink. The response would simply be a success statement - rendered on the webpage, there is a recipe for that on the site, which I have already created. To avoid confusion my enquiry was just how a POST would work differently to a GET request. Sorry if I am confusing anything.

20

The only real difference is that with a GET, you can only pass information in the URL itself such as query parameters. With a POST, you submit a message body with headers. So, for example, you could send some JSON.

Of course, a URL is just a string so a GET can be done with any old browser if needed whereas a POST requires something that formats and sends the data.

There are other verbs as well such as DELETE, PATCH, PUT. See:

https://www.restapitutorial.com/lessons/httpmethods.html

The http in node in Node-RED doesn't do any information processing no matter what verb you use, But it gathers up all of the info and puts it into the msg in a usable form. Up to you what actions you then take.