According to REST principles, there should be at least PUT & DELETE methods…

I also think that supporting the whole set of verbs (also HEAD) would be a good move. What is the reason to leave them out?

Looking forward to the next post about cross-domain.

Greetings,
Laurent

The code base of large applications get way too complicated when using asynchronous communication. Just look at your (very small) post example above. With synchronous communications, it would have been a one-liner. In large applications with hundreds (if not thousands) of web service calls that has to be called in specific sequences, this is not maintainable.

The burden it places on the programmer with regards to state handling is simply too great for many applications.

And of course, it should be posible to do synchronous communications in background threads to avoid blocking the UI.

At the very least, I think you should implement a standard way of calling out through the XmlHttpRequest object. As it stands, everybody has to create their own wrappers for this. I know that the XmlHttpRequest is limited in what it will do, but for many (most?) applications it will be enough.

Also, you need to support all the HTTP verbs, return the exact status codes from the server, and allow for access to all ports on the server (if the server allows it).

Thanks!

I see Silverlight as finally enabling the creation of an awesome RESTful client - why cripple it?

I hope there is still time to fix these before 2.0 RTMs.

Sure, for cross-site access limit me to GET/POST, if that’s what you need to do. But please do not limit the 80% use case (for me) which is talking to my own server!

I can’t think of anything worse than having to stick with JavaScript, just for XHR!!

As Andrew pointed out, the verb, status code and other HTTP capability limitations bound by the fact that the browser plugin networking APIs do not support things beyond what we’ve exposed. We wanted to use the browser stack (in order to get browser-enabled caching, auth, cookies, etc). And we also wanted to enable cross domain support, which meant not using XmlHttpRequest. This left us the browser plugin networking stack.

We are definitely evaluating what we can do here in the short term and long term, and your feedback is especially helpful in this area.

Also note that you are, if you really need to, able to access the XmlHttpRequest object via the HTML Bridge feature in managed code. After I finish this series, I’ll try to publish a full sample on how to do this.

As to supporting asynchronous only requests, this is also a result of browser limitations. The browser plugin networking API only exposes async requests on the UI thread. Enabling a Silverlight synchronous request would result in a deadlock: we would block on the synchronous request and then never get the asynchronous callback from the browser. Moreover, though, the idea of a blocking call on the UI thread (which would affect the entire browser UI) seems like something we don’t want to encourage as a platform. We are looking at expanding what you can do with the WebClient class so as to make certain types of calls easier and reduce the scenarios that someone would need to use the HttpWebRequest class directly.

Anyways, thanks again for the read and the comments - keep them coming!

Thanks,
Karen

- Tunneling verbs through post (”POST Tunneling”).
Many firewalls today only allow GET and POST verbs through.
Some web services look at the X-HTTP-Method-Override header
on posts. If X-HTTP-Method-Override is “DELETE”, the server
treats that request like a DELETE.

- Returning errors in the response stream.
Since returning status codes is a limitation for any plugin
using the browser’s networking APIs, some web services choose
to always return OK and then serialize an error message in
the response stream.

We definitely understand that these limitations are less than ideal, but hopefully after reading this post, you have a better understanding of why certain tradeoffs were made in the SL2 timeframe.

There’s socket support now, so why couldn’t there be a native HTTP stack that bypassed XHR and all the limitations that implies completely? Wouldn’t it be much easier to spin up a new thread and on that thread synchronously deal with the post operation where you could capture progress events? From a programming model that’s much easier. Alternately if there was someway to implement the API in such a way that progress events can fire as the upload is in progress that too would help greatly…

The GET / POST methods are okay, since we can use the x-http-method-override pattern.

I am concerned about the limited support for HTTP response codes. How would we handle a 401 to implement security?

A real world example of something I am working on is to consume RESTful services in a SilverLight client via a server, which is secured using digest authentication. It would seem awkward to navigate to the web server and be prompted with the browser’s default credentials dialog prior to even downloading the SilverLight application. How would we do this in a cross-domain scenario?

I also noticed that the WebClient class does not even have a Credentials (ICredentials) property like the full framework.

Cheers,

Stuart