Skip to content

0.9.4

Latest
Compare
Choose a tag to compare
@Ammonite-Bot Ammonite-Bot released this 22 Jul 14:07
· 6 commits to master since this release
080f2f3
[RFC] Allow overlap between static routes and wildcards (#134)

This changes the DispatchTrie to allow overlapping wildcard segments in
paths with static ones, with a preference for the latter.

For example, consider the following routes:

```
@cask.get("/settings")
def settings() = "settings"

@cask.get("/:id")
def user(id: String) = s"user $id"
```

This is currently not allowed. With these changes, it would be allowed,
and the static route `settings` would be preferred, with a fallback to
the dynamic route `user`:

```
GET /settings => settings
GET /foo => user foo
GET /bar => user bar
```

---

The reason I'm proposing this change is mostly for use in HTML
applications (i.e. not RPC-style JSON APIs). In this scenario, short
URLs are useful, since users may type them directly and associate
meaning to them.

Consider for example the way GitHub structures URLs. If github were
written with cask's current routing logic, it would not be possible to
have URLs such as `/settings` and `/com-lihaoyi`, and instead some
namespacing would need to be introduced (e.g. `/orgs/com-lihaoyi`) to
separate these, which might not actually be relevant for users.

Of course, with these changes we will no longer catch developer errors
that accidentally define wildcard-overlapping routes with non-wildcard
ones. It will also be up to the application developer to make sure that
there aren't any accidental overlaps between valid values of wildcards
and static routes (e.g. in the example above, the application developer
would somehow need to make sure that there isn't a user called
"settings" in their system).

Given these drawbacks, I'd like to hear your thoughts on this in
general. Personally I think that it's useful to enforce non-overlaps for
API purposes, because this forces you to design a more robust url
scheme. However, for HTML application purposes, I think that allowing
shorter URLs is useful and probably outweighs the current limitations.
Maybe we could also come up with a way to make this configurable.