Allow nil HTTP Server Decoders

[jdolce]

Currently http. NewServer() requires that you pass in a decoder otherwise it will panic in ServeHTTP(). This is slightly annoying for routes that have no input to decode. For instance GET /users, or something similar. For now I just created a common no-op decoder that I use in these cases, but it would be nice to simply pass nil.

The change is rather easy, and I am happy to provide a PR. Just wanted to make sure I wasn't missing some use case as to why it is this way first.

[peterbourgon]

My gut reaction is that I don't like special-casing nil for things like this. But I think it may be a nice affordance. I'd take a PR, but please be sure to make it universal: a nil encoder or decoder in any constructor that takes them (think: at least all of the other transport.NewServers) should have the same behavior.

[jdolce]

@peterbourgon The other option is to provide a default no-op decoder that everyone can use without having to re-write it or import a separate package.

[peterbourgon]

Yeah, I think both options could work! I've got no specific preference; what do you (or others) think?

[jdolce]

Thinking about it more I like the No-op decoder option better. If this was just something that I was building for myself I might say that nil is fine and carry on. But bigger picture I think you gut is right on the special-casing for nil. Even if all encoders and decoders behave similarly, you might start to wonder where else this might apply.

[ChrisHines]

In these situations I like to ask the question: Which option will make application code more readable and self documenting?

I think a NopDecoder would prove more readable than a plan nil.