In the meantime do you propose to rely our production on the beta version or the nightly builds?
and is there a stable version after the Beta?
Because relying on Beta in our production is one thing, but relying on nightly builds that are not stable is quite another thing...
Also is there a recap somewhere of the major differences between the beta and the currently nightly build?
I'm just a consumer of the Web API like you, so I'll give my thoughts on this.
I am in fact going to be using the pre-release versions of the Web API in a production environment. I currently build from source code as needed and update as needed, including my soon to be production environment.
I am doing this with the knowledge that it is a risk and it is a risk that I am responsible for -- not Microsoft. Beta is beta, not "release". The nightly builds are nightly builds of pre-release software. Use at your own risk. If
you are relying on pre-release software, it is your responsibility. If you are not comfortable with that, wait for the release version. Personally, I'm at a point in our product where I need to make a decision that will set the direction for the
next couple of years most likely. I want our API to be based on MVC 4 / Web API so I'm willing to take the risk. I feel comfortable enough that if I run into trouble, I'll be able to find a solution -- either in the source code, in the community,
I will say that if you are planning on sticking with MVC 4 / Web API, go with the nightly build. Too many awesome (but not all backwardly compatible) improvements since Beta and if you plan on switching to the release version when it comes out, you'll
have much less refactoring to do.
If you want to keep up with what has changed since Beta, follow the git repository commits; they are usually fairly detailed. Read the forums. That's all part of open source and pre-release software.
As to your original question, while the Web API method returning HttpResponseMessage may not feel right, it seems to be a very clean way of allowing various types of data to be returned and still have full flexibility for content negotiation, status code,
headers, etc. I'm sure someone can come up with a slicker way to do it, but the current implementation seems to meet the needs of a robust RESTful Web API quite nicely.