I fail to understand why the use of the node-red flows in combinationt with the node-red editor is an anti-pattern. From my point of view, Node-Red is an excellent rapid prototyping environment. Using Inject nodes or similar to trigger a chain of events is very simple, and as I see it where node-red shines in comparison with other environments.
Web applications that interact with a node-red backend, is one of many ways to design a system, but it is far from main stream.
Most of my node-red deployments have no specific UI requirements, and having to create a web application is just a lot of work for no value.
I completely agree that node-red is the best rapid-prototyping system I've used, and the most fun! The anti-pattern comment was mostly tongue-in-cheek, since we keep hearing about how the node-red editor is NOT meant to be a "dashboard". In reality, many of us (including me) do use it exactly for the purposes you are describing.
I disagree that surrounding your flows with http in/out nodes is a lot of work, or out of the main stream. They provide a very simple, targeted way to allow non-admin users to trigger parts of my flows without direct access to the entire editor. No web application needed for the end users, just a browser and a url.
And since you were specifically looking for a way to write a generic flow that makes an http request back to the same node-red server, without hardcoding the host:port/path info -- having the msg.req properties would certainly add value to your flows. Anyway, if you do find a more generic way to call back to the same server, please post your solution here for the rest of us. Best of luck...
__
Steve