Recently there was a question on the forums asking why we encourage usage of HttpRequestMessage<T> / HttpResponseMessage<T> in the signature of a web api implementation. The point made in the post is that if you have an ICalculator contract which your API implements, then it’s violating SOC / inappropriate to have those messages as params and in the contract. The argument is valid when looking at HTTP from the standpoint of an RPC mechanism, which is actually a quite common view.
Not of the HTTP authors though. If you read Roy Fielding’s dissertation you will see very clearly that:
HTTP is not a transport protocol and HTTP is not RPC.
You might be shocked dear reader, but it is a fact, it is not dogma.
There are real quantifiable reasons for this that underly the
foundations of how and why the web infrastructure was built. Roy
explains it much better than I can, though I still continually attempt to do it 
I recommend reading what Roy has to say on the subject here in sections 6.5.2 and 6.5.3.
Back to our Http messages. This has deep implications in your API design. Once you accept that the thing that you are exposing is an HTTP resource which clients interact with via the uniform interface and not a class with standard OOP methods, you design them differently. Your APIs become a gateway where HTTP concerns are addressed and then work is delegated off to the business domain rather than being part of the business domain. Once they do, you can safely use HttpRequestMessage<T> and HttpResponseMessage<T> without fear as they are for address HTTP concerns.
You can read more about the design implications from a Web API perspective in my reply on the thread.
Interested in your thoughts.
Source:http://codebetter.com/glennblock/2012/01/19/http-is-not-a-transport-protocol-http-is-not-rpc/
