service provider support

[loganwright]

Moving here from #48 w/ conflicts resolved. Can overwrite 48 if preferred.

[tanner0101]

Request.Handler should return a Response, not a ResponseConvertible. I want to keep all Response conversion in the Router / Application.

Use Route.Handler to refer to a request handler that returns a ResponseConvertible.

[loganwright]

@tannernelson updated to retain that functionality

[tanner0101]

Should not need to convert to .response() now.

[tanner0101]

Oops sorry if I wasn't clear. I think the Route handler should be on the Route class.

ResponseConvertibles are resolved to Response's before they are even registered to the Router.

I'd rather keep the ResponseConvertible logic as isolated as possible so that middleware and routers etc can work with the simpler Request handler.

[tanner0101]

Check the closed PR to see my implementation.

[loganwright]

@tannernelson In the new setup, we omit the need for a global Routes array which I think is preferable for users who may want to implement a custom Router since it's much more modular. By converting inside of the Router, we allow access to the simpler -> Response, which accomplishes the same effect in Middleware. Or am I missing something?

[tanner0101]

Oh, I see what's happened.

The API for adding routes was moved to the Application class.

app.get("test") { request in
    return "test"
}

I think this API is very clean. You register your Route.Handlers with the application, then upon booting, the application resolves all the Route.Handlers to Request.Handlers and registers them with the chosen RouterDriver.

This isolates ResponseConvertible to the Application class and also creates a separation of logic between defining the routing logic of your application, and actually registering paths and handlers into a RouterDriver.

[tanner0101]

If you copy the Route.swift file from the closed PR, it has all the missing pieces.

[loganwright]

@tannernelson I see where we missed each other, updating now.

[loganwright]

@tannernelson Ok, the syntax has been returned to the application, I like this way much better since it omits the need for a singleton while still keeping interaction simple and clean. Good choice! It also works better for the router since we can rely on its registration component and leave modularity easy for swapping in a new RouterDriver if a user wants to do that.

[tanner0101]

Is there a more descriptive name we can give this router? Like BranchRouter or something?

[loganwright]

Yea, definitely

[tanner0101]

This looks great. Do we still have support for hosts?

app.host("google.com") {
    app.get("test") { request in 
        return "this is only available at google.com/test"
    }
}

If so, let's just see if we can write a few tests to ensure middleware / providers are working and let's merge this.

It will be release 0.2.0.

Also we should update all dependencies on vapor, like vapor-example, to specify 0.2.x because this change is most likely going to break people's projects.

[tanner0101]

Everything looks good. Did we add any new tests with this?