This project is read-only.


Topics: Web Api
Apr 25, 2011 at 5:54 PM

When should I use HttpResponseMessage<T> as a return type? Is there any rules? In sample project sometimes the return is a HttpResponseMessage<T> and sometimes the pure object.

I also have noticed that in the last preview I can't use void on a service. In the examples, when a PUT is used, the modified object is returned to the client but I don't use it like that. I always return a void. Now what should I do?


Apr 25, 2011 at 9:31 PM

You use HttpResponseMessage<T> when you want to change some response headers directly from within the Operation.  The long term goal is to have OperationHandlers that sit in the Response pipeline that will set headers based on some "standard" application logic.  However, for cases that are not handled by your OperationHandlers then you can access the headers directly by using HttpResponseMessage<T> without losing the benefits of automatically converting your strong typed object into a representation.

A PUT method still returns a response even if it does not contain an entity body.  I believe you can simply do return new HttpResponseMessage(); if you don't want to change the default response. 

Apr 26, 2011 at 5:10 AM

But now I feel that my operations are more coupled to the API. It's not necessarily a bad thing, but the code is not so "clean" as it was and can break many operations if you change these classes. Remote chances to happen but boring stuff to fix.

I know that a PUT (and other methods too) has to return a response, but why should I have to write an empty response if the API can do that for me? It would be better if it was optional. I should only reference the response message if I wanted to handle it in some way.

What am I missing? I really like the previous way and haven't seen the benefits of this change. IMHO

Thank you Darrel.