The past week I’ve been working my way through figuring out why I’d been getting a spate of HTTP 400 – “Bad Request” errors coming back from my RESTful WCF services.  In my case, the requests were POSTs, and the client was a C# web app with access to the contract POCO that was being passed as the parameter to the WCF service call.

First step: build a PowerShell script that simulates the request using standard HttpWebRequest/HttpWebResponse classes.  Take WCF out of the equation on the client.  In my case, I’ve been using the new Microsoft.Http namespace from the client, which I’m not sure is very tied to WCF anyway, but….

Second step: Create the simplest service method possible.  In my case, it was a HelloWorldPost(string name) method that returned “Hello, {name}” back to the caller.  This was decorated with a WebInvoke() attribute with the proper properties.

Third step: run the service in the debugger.  Then run your PowerShell script.

This third step may or may not work.  There is apparently some plumbing in the WCF catacombs that intercepts the request and checks for Very Bad Things before your service method even gets to it.  In my case, the breakpoint never hit, so I knew it was something more fundamental.

Fourth step: RTFM.  The FM in this case is the built-in WCF help page at http://yourhost/yourservice/help.  Surprisingly enough, they tell you what the payload should be for Bare requests, which includes, for XML payloads, the proper XML wrapper-y stuff and namespace.  It turns out that if you use that exact format for your POST body payload, you may very well eliminate the HTTP 400 Bad Request error.  In my case, that’s exactly what happened.

I can’t say I’m thrilled with the need to mark up the plain content with XML, but I’m familiar with it enough from other SaaS environments (Twilio and YouMail come to mind) that I know the deal.  And, I’m not totally ready to make the jump to thinking primarily in terms of JSON interactions.  Yet.  I’m building this service for use by a C# web app, for now, and will get to JSON when and if I need it.

Fifth step: Use Fiddler.  Within Fiddler you can inspect the hell out of the request and response objects, and even create your own requests on the fly.  This is IMHO an indispensable tool for building and troubleshooting WCF clients.

So, back to my original problem – why did my C# client, which was using the proper DataContract POCO, fail?  It turns out that if you have an uncaught exception in your service method, WCF will return HTTP 400 Bad Request:

This OptimisticConcurrencyException will result in an HTTP response with a status code of 400 (Bad Request) and HTML content that explains that the server encountered an error.  This is the default behavior for unhandled, non-WebFaultExceptions.

Hope this helps some of you struggling with HTTP 400 Bad Request errors when writing and testing your RESTful WCF services.