Node-red served URL list

I recently rediscovered node-red-contrib-web-worldmap installed on one of my Pies, and it has the worldmap example flows.
This means that there's a bunch of maps available at URLs such as 192.168.1.27:1880/basicmap, 192.168.1.27:1880/worldmap1, etc. The URL is specified in the widget config

This Pi also has the original and flowfuse dashboards, each of which has it's own sidebar with a button to open the dashboard.

You can also create end-user web pages with Uibuilder, HTTP nodes and doubtless many others.

Should there be an editor sidebar panel to identify, list and link to the available URLs?
I suppose any URLs served by a different webserver than Node-red's own should not be included.

This is a good question. And not necessarily an easy one to answer.

Ideally there would indeed be a master index of end points serviced from Node-RED. However, ExpressJS which is the web server that Node-RED includes is particularly appalling at allowing you to do this. And, of course, we are currently stuck on ExpressJS v4 whereas development (which had pretty much stalled for several years) is now focused on v5.

UIBUILDER does provide a list of its end points both as a web page and as an API. But it builds it internally. But even that cannot list everything since you can certainly create pages and sub-folders that are delivered by uibuilder and markweb endpoints.

So bottom line is - yes, there really should be a master list of Node-RED managed endpoints. But it appears to be a hard problem.

Perhaps people with more experience and knowledge can find a solution. I would certainly be happy to adjust UIBUILDER to feed into a master list.

OK well Dashboard 2 has a [fixed] ui-base and multiple ui-pages where the config defines the URL
Dabshboard 1 has a single page and multiple tabs.

It should be fairly straightforward to obtain these from the flows file, slightly more complicated, but useful, to distinguish between pages or tabs with and without any enabled content.

But Node-red could surely offer a mechanism where any component can register how to find the URLs it creates. (I don't suggest registering the actual URLs because then there's scope for omitting some)

eg Worldmap nodes are of type "worldmap", and have key "path"

A deploy would trigger recreation of the index of pages, and a sidebar, perhaps even the Explorer, would present the index as hyperlinks,

Couple of points there. I believe it was always intended to eventually allow the base URL to change, it hasn't been implemented yet.

In regard to D2 "Pages" - don't forget that they are not actually "pages" in an HTTP sense, they are front-end routed virtual pages. Unless I've misunderstood, this is actually the same as D1 but better hidden I think?

Not that easy - see my next comment. However, yes, this is how UIBUILDER does it. In UIBUILDER's case, it adds a few Express Router's and attaches endpoints to them. As it does these things, it maintains a list of everything that has been added. These are shown on the "Full Details" link in any uibuilder node.

The harder part stems from the fact that Node-RED provides so much flexibility in terms of its configuration. This means that root URL's may change based on settings in settings.js. These settings have to be taken into account as well. Certainly possible but just a little more complex. This is why I always recommend and use relative URL's in UIBUILDER.

That is an interesting take on things. A standardised search API for finding endpoints. Not sure how that would work but it sounds feasible maybe. Rather more complex than getting nodes to register their endpoints though.

The other complexity either way would be the need to indicate whether an endpoint URL was a leaf or a branch. Branches would, of course, allow further sub-folders and pages, leaf's would not.

and type of either "leaf" or "branch". Possibly you might also want to indicate whether branches were server-side or client-side. For example, a uibuilder node's "URL" setting can actually be either a server-side branch (since it uses static serving) or a client-side branch (using the uib-router for an SPA) or even both. Either way, the node does not actually "know" all of the possible end-points. This gets even worse (or better depending on your viewpoint) for Markweb nodes because, while all of the pages are server-generated, the generation is fully dynamic and tracking all of the possible endpoints from a large content website would certainly be a large dataset to manage. It could amount to 10's of thousands of folders and pages.

None of this is insurmountable of course, I'm just highlighting some of the possible complexities that would need to be thought through.

We perhaps also need to think about the split between the admin and user web servers that Node-RED maintains and the fact that any node can create additional web servers - uibuilder has that as an option of course. Websocket endpoints also need to be accounted for. And http-in nodes allow wild-card server endpoint definitions as well.

If that happens I'll eat my hat!
But it's true you can change it from /dashboard to /somethingelse by editing the flows file. Probably doing so has side-effects.

Hope you have a tasty one! :rofl: I seem to remember there is a disabled input for it in the settings. It should be possible though since D2 is "only" an SPA. In other words, I think it only has a single actual user-facing endpoint.