More elegant handling of edge HTTP requests

Hey Team!

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:

  1. 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”).

  2. 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!

-FL

@Frederick_Loucks,

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.

Thank you,
Heath

1 Like

@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.