Confusing use of leading slash to define routes

[EricCarlstrom]

I'd be surprised if this wasn't a common point of confusion... when looking at the sample project, and code such as:

        self.router.registerHandlerClass(DPLMessageRouteHandler.self, forRoute: "/say/:title/:message")

Most will presume this translates to an URL such as my-app://say/someTitle/someMessage... but in reality you must register the route without the leading slash

I'd propose making examples and README more explicit by showing corresponding external URL for each and every registration example, including, perhaps, comments in the sample source itself.

[wessmith]

Hi @mixedrice

We made this decision because iOS apps don't have a unique host and it would be unclear how to register a route for "my-app://say/someTitle/someMessage" vs a route for "my-app://mycompany.com/say/someTitle/someMessage".

The decision is based on Apple's docs on NSURL and the URI RFC

Per RFC 3986, the leading slash after the authority (host name and port) portion is treated as part of the path. For example, in the URL http://www.example.com/index.html, the path is /index.html.

It is covered in the README but perhaps we could move this up a bit and reference it more.

Thanks for the feedback!

[EricCarlstrom]

Yeah, fair enough... perfectly reasonable implementation, and does offer flexibility/consistency with the host-name pattern.

I think for me, I'm still drawn towards optimizing for the use case (and I could be presumptuous here) of most folks leveraging custom URLs in native apps as simple command relays and lightweight routes (and ignoring the host component)... the temptation, right or wrong, is to overload the host with what normally be the first component of a path in traditional URLs.

I think annotating the code examples with working URL's would totally get the job done.

Appreciate the help!

[chrismaddern]

Annotation SGTM.

Hopefully with Universal Links, scheme based is less and less common and host will always be there :D