Routing

[Mark Rendle]

Not worked this into a proposal yet, so opening up for discussion on group.

Routing is a complicated problem and one that people continue to solve in new and interesting ways. It's also something that can benefit from being handled very early in the pipeline. For example: if all you're going to return is a 404, do you really need to waste time and resources authenticating a request? No.

So I think there's an opportunity here for defining some kind of common standard for Routing middleware. I don't want to get too prescriptive, but it seems to my little brain that any module could be provided with an IEnumerable<string> of valid routes, and add a couple of keys to the dictionary along the lines of:

• routing.Matched: string: The template that was matched, e.g. "customers/{Id}"
  
• routing.Values: IDictionary<string,string>: Any values extracted from the actual URI, e.g. { { "Id", "42" } }
• (No need for <string,object> since a routing module wouldn't be able to infer types for values anyway)

Things I'm not clear on, though:

• Ambiguous matches. How likely is it that (a) there may be more than one matching template for a URI, and (b) the handling framework may be able to do something intelligent anyway?
• If that's a thing, then obviously a simple string + <string,string> won't work
• I don't know if I'm suggesting there MUST be a separation of routing and other concerns, or there SHOULD, and
• I also don't know if I'm suggesting that all frameworks should be able to work with all routing libs, requiring standards for the URI templates themselves (e.g. wildcards/regexes/etc)

So, what are people's thoughts? Yes, you, I'm talking to you.

Cheers,

Mark

[Diego Fernandez]

Mark,

Thanks for opening this discussion.
I personnaly find this very important, but at same time, controversial.

We are used to see template matching techniques but what about graph based routing?
I found this framework http://superscribe.org/ and it opened my mind about routing.

I am only concerned how would we handle very different approachs and still have a solid spec.

I'll try to contact the author and ask for contribution since superscribe supports OWIN.

[ste.r...@gmail.com]

I don't think anything beyond mapping urls to middleware chains is necessary at the OWIN level, and even then I don't think it needs a "spec". Its something that various middlewares can provide and combine to create functionality for the end app in whatever way the app author wants.

Sent from my Windows Phone

---

From: Diego Fernandez
Sent: ‎27/‎06/‎2014 18:30
To: net-http-a...@googlegroups.com
Subject: Re: Routing

--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Rendle]

Superscribe was part of my thinking on this, the idea of routing as a first class citizen. I hadn't seen the examples of the non-template route configuration; I thought it parsed regular templates and did its graph thing on the generated tree.

And to be clear, I'm talking more about common keys and an agreed convention rather than a spec, so people can write route-aware middleware. So the way the route is configured is less important than the way it provides route data in the OWIN Environment.

--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Mark Rendle

Founder, Zudio

[Damian Hickey]

This topic has been knocking around my skull for some time. I don't quite agree with Steve - I can definitely see a need for something a bit more that MS.Owin's Map path MW, at least at a personal level. It seems to be the natural direction of 'everything MW' being the future of web apps. AspNet vNext has already externalized routing to middleware.

I just don't know if the topic is too nuanced or not for it to become standardized whether common keys or spec. Watching this one :)

To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Pete Smith]

Good to see routing in OWIN getting some attention... it is a pivotal part of most web apps after all :)

I think there's tremendous value in defining some default or even 'standard' environment keys. I like Mark's suggestions so far, but would probably suggest Parameters rather than Values. I'm also not yet sure if 'routing', 'route' or even 'routes' would be better as the prefix.

I'd think the following would useful:

• routing.Matched: string: The template that was matched, e.g. "customers/{Id}" or perhaps "customers/{0}" (see below)
• routing.Parameters: IDictionary<string, object> - We shouldn't preclude routing algorithms such as graph based routing where parameters can be strongly typed.
• routing.Table: IDictionary<string, string> - Named list of possible routes, which can be used to generate links

As Mark mentioned above, one problem is deciding on a standard format of the route template value and the strings in the route table that all middleware can work with. The simplest solution may be to represent a route like this:

route.Matched: "api/customers/{0}/Orders/{1}"

route.Parameters: [{"customerId":123"}, {"orderId": 321}]

If the parameters are added as they are matched then generating a link is just as simple as doing string.format(route.Matched, route.Parameters.Values). The downside is that this doesn't really reduce the overall complexity and makes the templates in the route table harder to read, but it does shift it so that the writer of a middleware doesn't have to re-implement any link generating boilerplate.

Looking at the other 'uncertain; items from Mark's list I have some further thoughts:

• Ambiguous matches. I believe if a routing framework encounters an ambiguous match, then this is a configuration error and the pipeline should abort and return a 500.
• Separation of routing and other concerns - This is definately a SHOULD - if a framework wants to do it's own routing then fine (not sure why this would be useful), but there are some obvious advantages to seperating the two:
• Testability - If a framework has a method that takes resolved route data then this is a nice way to test things in isolation.
• Performance - Routing is done up front as part of the middleware pipeline. If an app is composed of multiple frameworks (rare) or if the pipeline needs to branch based on the route (more likely) then routing need only be done once.
• Maintainability - No need to keep routes in sync in multiple places in your code.
• Standards for the URI templates - See above

On a final note, the whole concept of a web framework is on the way out as we seen an increasing trend towards modularity. In my opinion if current open source frameworks are to survive into vnext then they will need to adapt accordingly and split ALL of their concerns into different middleware, not just the routing. How cool would this be:

app.UseSimpleWebRouting().
   UseNancyModules().
   UseWebApiViewEngine()

No more 'framework' wars, just pick and choose the components that are best for your app on their individual merits. That's the future I want to be a part of.

[Mark Rendle]

Thanks Pete, I think we're seeing the same possibilities here around modularity. I can't see my original post and I can't remember if I said this, but having the route as a first-class environment value also helps with things like logging, analytics, and so on. I think Glimpse shows the matched route for ASP.NET MVC, it would be good if it could do that using a standard in OWIN.

I agree that Parameters is a better name for the value dictionary, and I'm happy with the <string, object> to support types if they are available.

Regarding the Matched format, it would be problematic for various frameworks to lose the naming of parameters. Simple.Web matches the names to properties on the handler classes, and I think Nancy names the dynamic properties based on them. I guess it's something that could be worked around, but I think if the framework declares names they need to be honoured by the rest of the pipeline.

Cheers,

Mark

--

You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Damian Hickey]

Count me in on the its-all-going-to-be-mw train. There will always be a place for the larger does-it-all frameworks. But the direction I am personally going in is modularity and composibility at a finer granularity.

[Sebastien Lambla]

We've had conversations to find some common ground between routing, especially as it's the first component I'll probably release in the OR3 family, as it's the most complete.

That said, I'd rather keep it a discussion between implementers of it, form a draft we pre-agree on and then submit it to owin shall we decide it's worth standardising, dragons ahead if we start anything by trying to design by committee.​

---

From: net-http-a...@googlegroups.com <net-http-a...@googlegroups.com> on behalf of Damian Hickey <dhi...@gmail.com>
Sent: 29 June 2014 12:32

To: net-http-a...@googlegroups.com
Subject: Re: Routing

 

Count me in on the its-all-going-to-be-mw train. There will always be a place for the larger does-it-all frameworks. But the direction I am personally going in is modularity and composibility at a finer granularity.

[Sebastien Lambla]

The real question is, how much of "routing" is coupled to the "framework", decoupling the two is a very important piece, but the same could be said of request to object mapping and object to response mapping. We need to be careful about not wanting to standardize everything and leave nothing to framework / library authors to innovate on.

---

From: net-http-a...@googlegroups.com <net-http-a...@googlegroups.com> on behalf of Mark Rendle <ma...@markrendle.net>
Sent: 29 June 2014 12:05

To: net-http-a...@googlegroups.com
Subject: Re: Routing

[Ryan Riley]

I concur. I’m not sure there’s anything needed other than the URL bits we already have. I’d be happy to be convinced otherwise.

On Jul 1, 2014, at 6:31 AM, Sebastien Lambla <s...@serialseb.com> wrote:

The real question is, how much of "routing" is coupled to the "framework", decoupling the two is a very important piece, but the same could be said of request to object mapping and object to response mapping. We need to be careful about not wanting to standardize everything and leave nothing to framework / library authors to innovate on.

---

From: net-http-a...@googlegroups.com <net-http-a...@googlegroups.com> on behalf of Mark Rendle <ma...@markrendle.net>
Sent: 29 June 2014 12:05
To: net-http-a...@googlegroups.com
Subject: Re: Routing

 

Thanks Pete, I think we're seeing the same possibilities here around modularity. I can't see my original post and I can't remember if I said this, but having the route as a first-class environment value also helps with things like logging, analytics, and so on. I think Glimpse shows the matched route forASP.NET MVC, it would be good if it could do that using a standard in OWIN.