You define a closure to handle requests matching paths with type-safety. You are passed the correct parameter types and the correct amount of parameters directly to your closure. This gives you compile type safety.
// Handle GET requests to path /users/{username}
get("users", *) { (request, username: String) in
return "Hello \(username)"
}
In contrast, without this compile-time safety you will most likely be passed an array of Strings and you will have to pull items out.
Route.get("users/:username") { request in
if let username = request.parameters["username"] {
// Return something with username
} else {
// TODO Return 404
}
}
Here you have to manually validate these parameters, there is also the lack of compile time safety in the way you are writing a hard-coded string for each parameters. There is a string "username" twice, both the path and when you pull out the parameter from the array. There is a large room for user error or typos here.
Thanks for the clarifications. As soon as web text-based protocols were mentioned, I said "oh duh" to myself. There's nothing about the availability of a type system that forces a plain-data wrapper library to use it.
The mistake most of these make is they are both web frameworks and they have their own build in web server. We should learn from mistakes in previous communities such as in Python (https://www.python.org/dev/peps/pep-0333/#rationale-and-goal...) and not tightly coupling these things together.
A user should be free to choose their favourite web framework and then choose the best web server for their needs.
> We would like to provide a package index in the future, and are investigating possible solutions.
[1]: https://github.com/apple/swift-package-manager/blob/master/D...