Why is HTTPRoute.method not of type HTTPMethod?

[tonyarnold]

https://github.com/swhitty/FlyingFox/blob/b3f2ed19bd05d1228949a5548efce06a69850143/FlyingFox/Sources/HTTPRoute.swift#L35

I'm working on a solution for #89, and I've noticed that this property is typed as a Component. I'd love to know more before I start making changes?

[swhitty]

I just made up the syntax one day with some regrets now, but this was really just to allow routes to any HTTPMethod

/foo is equivalent to * /foo

Using Component was just lazy reuse of the same type representing the path components, so happy for that to change. It could simply be HTTPMethod? with nil representing the wildcard or something else if we wanted to express a finite subset of methods

(GET,PUT) /foo etc.

[swhitty]

The other regret is interpreting a trailing * as a recursive subpath

/hello/* matches both /hello/fish AND /hello/fish/chips.

I would have now preferred to be explicit about this using ** for this recursive subpath matching

[tonyarnold]

I hadn't considered a subset of methods. ~Perhaps it should be an OptionSet, or an array of HTTPMethod… I'll play with the OptionSet idea.~

I forgot that OptionSets are numeric. The stringiness is good here, I think.

[swhitty]

The stringiness is good here

Agreed, one may want to test using non standard methods for whatever reason.

[tonyarnold]

What about something like:

GET /some-url-1
GET,PUT,POST /some-url-2
/some-url-3

Not specifying a method currently seems to infer all methods — perhaps this should be restricted to GET in future.

That's simple enough to parse.

It would mean making the var method: Method into something like var methods: Set<Method>.

[swhitty]

I plan on pushing out 0.15.0 later this week which includes these changes.

[tonyarnold]

Wonderful, thanks Simon! I'm sorry I haven't made much time to look at my follow on changes over the last few weeks. I'll try to make some time.

[swhitty]

Released in 0.15.0