I have been struggling recently to find a way to model a REST like (not quite RPC but close) service on the Web server using ASP.NET. I forgot why but I was mislead some time ago and spent quite some time researching remoting only to be reminded that .NET services probably support some form of REST like functionality - the first was Don Box post about Microsoft investments in REST and the other was an answer given to my inquiry several months ago in one of Microsoft forums.

Having anything but SOAP supported on the wire is actually very undocumented (but it is supported!) and hard to get right. After about one day of struggling with Visual Studio 2005 (therefore .NET 2.0) I have managed to get HTTP GET and HTTP POST support to work fine (and SOAP not to work at all) but after my dance with the server configuration I cannot get “Add Web Reference” to work any more and no code is generated for me on the client (this is not a big deal because I already built my own proxy mechanism). Here's a (hopefully) helpful hint - if you want HTTP GET/POST support, try adding it manually under system.web/webServices/protocols (clear all the protocols, then add what you need) in your web site's web.config.

Unfortunately I still have two big obstacles to overcome - parameter validation takes place “somewhere” and if you send a wrong type you get an exception trace back (I'd like to catch that exception and return something more meaningful) but even more important - I can't seem to find a way to return something other than POX back. Before someone mentions it, I don't want to bother with WSE 3.0 and MTOM (but I will if that is the only solution).

There is always an alternative - just like I built my client proxy stack myself (and it's not much of code and is very clean) I might opt to build the server one too. But it feels so wrong - the problem is well defined, everyone is having it and it would literally be inventing hot water.