I use the edge HTTP web server to serve a REST API for several microservices. I’ve found handling incoming requests to these services is cumbersome with the current implementation of the HTTP trigger node. I have a few ways we could probably make that better:
Filterable HTTP trigger node…allow filtering on the HTTP trigger node by method & path…or maybe even as a series of expressions. Ensure for path filtering we have glob / regex pattern handling (ie accept everything on path “/requests”, including “/requests/foo” and “/requests/bar”).
If this has to be handled outside the HTTP trigger node, then I’d recommend including complex statements and glob/regex pattern matching in the Switch node. Same use case. This would save me from needing to stack multiple conditionals and switch nodes just to route an incoming request. Right now in order to deal with path routing where I’m using namespaces I’m having to do a string node with a split or something similar. This also works for getting things like deviceIds out of paths for GET/PATCH etc. But would be nice if it were more elegant.
Would love to hear any other thoughts or suggestions!
This is a very reasonable request. Let me get with my engineering team and discuss which option lends itself to the more likely option and I will get back to you once I create the feature request.
@Frederick_Loucks I’m going to write this up as a feature request. Off the top of my head, I see it working something like the following …
Per HTTP Edge Trigger, you would have the option of firing the trigger on all requests or only on requests of a single method / path (i.e GET /foo/bar)
We would support wild cards (/foo/*), path parameters (/foo/{deviceId}), and optional path parameters (/foo/{deviceId}/{attributeName?}).
Unlike for application experiences, it would not be necessary to define edge routes as separate endpoints; matching would simply occur per trigger.
One gotcha is that a single HTTP request could fire multiple triggers (i.e. /foo/abc would fire triggers /foo/*, /foo/{deviceId}, /foo/{deviceId}/{attributeName?}, and a trigger configured to fire on all requests, whether those triggers are all in the same workflow or spread across multiple flows). If the request is expecting a response, you then have a race condition on your hands as the first workflow run to hit an HTTP Response Node would issue the response.
I need to talk to the engineering team about how much effort this is to support so I don’t have a timeline for you on when we would implement this, but I’ll keep you posted.
Per HTTP Edge Trigger, you would have the option of firing the trigger on all requests or only on requests of a single method / path (i.e GET /foo/bar)
Sounds about right…a text input for Method, and another for Path.
We would support wild cards (/foo/*), path parameters (/foo/{deviceId}), and optional path parameters (/foo/{deviceId}/{attributeName?}).
Yeah, wildcard/glob patterns would make things easy. Not sure how path params would work. Don’t know of any trigger nodes that allow path variables. But that would be awesome. Really like the optional params.
Unlike for application experiences, it would not be necessary to define edge routes as separate endpoints; matching would simply occur per trigger.
Agreed.
One gotcha is that a single HTTP request could fire multiple triggers (i.e. /foo/abc would fire triggers /foo/*, /foo/{deviceId}, /foo/{deviceId}/{attributeName?}, and a trigger configured to fire on all requests, whether those triggers are all in the same workflow or spread across multiple flows). If the request is expecting a response, you then have a race condition on your hands as the first workflow run to hit an HTTP Response Node would issue the response.
Seems you’d need to follow best practices here and ensure only one trigger node per path is instantiated in your edge workflows. Which is the same as it is now…I can set up multiple HTTP trigger nodes and put a response after each and the same race condition will occur. I think this can be trained/documented around. I also don’t know of a simple way to prevent this without some kind of request routing or centralized list of all inbound routes and assigning them exclusively to trigger instances…which sounds really complex to pull off.