Tide: Trailing slash

[secretfader]

When creating REST APIs with Tide, I expect code like the following will be fairly common:

let mut router = App::new();
router.at("/resource").nest(|router| {
  router.at("/").get(async move |_| "Slash");
  router.at("").get(async move |_| "Blank");
});

I don't think developers will type both routes often, but in the wild, it's highly likely that we'll find both techniques in use. Being a bit more explicit about how routes are added the looked up may be an option to prevent confusion going forward. When looking at the example, it isn't entirely clear how an incoming request would be handled.

As of this writing, Tide renders two different responses: "Slash" appears at the path with a trailing slash (/resources/), and "Blank" at /resources. Which leads to the following questions:

• Should Tide allow both a blank and slashed path in cases where the two are extremely similar?
• Does Tide require a configuration option to differentiate between matching paths with trailing slashes and empty paths? Do we enable this option by default?

I'm sure there are other considerations I haven't accounted for yet, and aware that this change could affect future work in route-recognizer. The above is merely a starting point for this discussion, and I'd like to hear what others think.

[yoshuawuyts]

Should Tide allow both a blank and slashed path in cases where the two are extremely similar?

We should probably treat the two as equivalent. There's even an argument to be made for disallowing empty paths "", and require folks type "/" so confusion can't occur in the first place.

Does Tide require a configuration option to differentiate between matching paths with trailing slashes and empty paths?

I don't think we should allow configuration of this. This is the kind of decision that feels like a bit of a bikeshed, and I see one of the benefits of frameworks over ad-hoc module collections is that you don't need to think about these kinds of decisions.

To me picking one option, and documenting it seems like the right way to go to.

[secretfader]

I agree that we should choose one path, @yoshuawuyts. My take is that we shouldn't allow "" at all, in favor of /. (It is admittedly a bit of a bikeshed, but not nearly as critical now as it will become. In my view, it's best to answer this now while the framework is developing.)

[ennersk]

I like the current strict path matching principles of tide, only one match, no magic, _compliant_.

As weird as this may be, http://acme.com/resource/ and http://acme.com/resource are different in http. @yoshuawuyts "We should probably treat the two as equivalent. " -> I think it is perfect as it is currently and vote for closing this one.

Anyways, see #492 for a similar issue of myself I want to suggest for improvement.

BTW: [Google] suggests to redirect the one to the other in case a dumb client needs it, that should be easily doable with tide - but manually, without magic, please :)