The more advanced a type system is, the more it depends on what you do with it when designing an API. A well designed API in a language with a rich, expressive type system can make higher-level guarantees. On the opposite side of the spectrum you could just use Strings for most of the types (it’s web after all!) and it would still be type safe, although the type guarantees wouldn’t be of much use.
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.
