A project I’m working on uses a set of WCF RESTful services to retrieve data for a Silverlight application. The main driver for using REST is to minimize the size of the data coming back- the services return a large amount of data that is grouped and aggregated in different ways on the client, and using JSON can result in significantly smaller messages.
First realization- WCF in Silverlight only supports BasicHttpBinding and PollingDuplexHttpBinding (and NetTcpBinding in an intranet setting). This means that you use a service client to create a client proxy in the Silverlight project. This is surmountable by using WebClient or HttpWebRequest and JsonDataContractSerializer to access the service.
The next fun challenge was with error handling. With RESTful services the intent is to use standard HTTP error codes to handle errors, rather than custom error codes or messages. I’m not in love with this, because I think forces you to pick codes that don’t quite match the intended error message. But OK, I could use HTTP 401 to indicate an authorization failure.
Or so I thought. Silverlight plugins use the browser to make requests, and because of restrictions in what plugins can access, they can’t see any details of HTTP errors. The browser doesn’t pass them to the plugin- you see ““The remote server returned an error: NotFound.”
Any HTTP error gets subsumed into an error like this- you can’t get to the detail message, or even the detail code- everything turns into either 200 or 404!
The only option for getting detailed error message is to return a success, and then include some indicator in the message body itself that there is an error. Obviously this is an ugly thing to do.
Extensive searching doesn’t turn up any way around this issue. The moral appears to be: if you want detailed error handling, don’t use RESTful services with Silverlight. Stick to SOAP.