IntroductionSilverlight gives users the ability to create an extremely rich UI experience for the user, but what about the server? How can I take advantage of Silverlight to do simple access to a server whether it's a LINUX Web Server or a Windows Web Server? What if I want to make REST calls to my server? Silverlight includes a few namespaces for doing simple request and response to and from the server: System.Net and System.Net.Browser. These assemblies contain the following classes that will allow us to talk to our server over the web: Class Description
WebRequestCreator Allows us to create a web request given a URI
HttpWebRequest A web request in which we can set our request
HttpWebResponse The web response coming back from the server With the help of just these three classes, we can do everything we need to do to push data from the Silverlight client to the web server and retrieve information from the web server into our Silverlight client.The Client Access Policy In order to have authorization to use Silverlight against the web server, the web server must have a client access policy file installed in the root. Without this policy in place on the web server, Silverlight will continue to throw authorization exceptions anytime it tries to contact a server on another domain with the classes listed above. Listing 1 shows a typical client access policy. This policy allows all headers to go through on a request and allows requests from all domains. It also allows you to use any of the http methods: GET, PUT, POST, and delete. You can restrict any of the access by simply replacing the wildcard asterisk in each tag with a more specific value. Listing 1 - Typical Client Access Policy <?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<!--Enables Silverlight 3 all methods functionality-->
<policy>
<allow-from http-methods="*" http-request-headers="*">
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/resources" include-subpaths="true"/>
</grant-to>
</policy>
<!--Enables Silverlight 2 clients to continue to work normally -->
<policy>
<allow-from >
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/api" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>Now that we got that out of the way, we can do some real work on the client. Let's start with a simple http GET method. Everything done in Silverlight is asynchronous. Initially the asynchronous world is a difficult planet to live on, but eventually you start to get the hang of residing on it and may even enjoy it. To implement a GET we first create a web request and then call it. The web request is created with the the convenient WebRequestCreator. You can think of the WebRequestCreator as a factory that churns out HttpWebRequest objects. Just feed it a uri and out spills a web request. Keep in mind that you still need to populate the request with the methods, headers, and data. Once you have your web request ready, just call the asynchronous BeginGetResponse and wait. Listing 2 shows an example of creating the request and making the asynchronous call. Read more: C# Corner
WebRequestCreator Allows us to create a web request given a URI
HttpWebRequest A web request in which we can set our request
HttpWebResponse The web response coming back from the server With the help of just these three classes, we can do everything we need to do to push data from the Silverlight client to the web server and retrieve information from the web server into our Silverlight client.The Client Access Policy In order to have authorization to use Silverlight against the web server, the web server must have a client access policy file installed in the root. Without this policy in place on the web server, Silverlight will continue to throw authorization exceptions anytime it tries to contact a server on another domain with the classes listed above. Listing 1 shows a typical client access policy. This policy allows all headers to go through on a request and allows requests from all domains. It also allows you to use any of the http methods: GET, PUT, POST, and delete. You can restrict any of the access by simply replacing the wildcard asterisk in each tag with a more specific value. Listing 1 - Typical Client Access Policy <?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<!--Enables Silverlight 3 all methods functionality-->
<policy>
<allow-from http-methods="*" http-request-headers="*">
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/resources" include-subpaths="true"/>
</grant-to>
</policy>
<!--Enables Silverlight 2 clients to continue to work normally -->
<policy>
<allow-from >
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/api" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>Now that we got that out of the way, we can do some real work on the client. Let's start with a simple http GET method. Everything done in Silverlight is asynchronous. Initially the asynchronous world is a difficult planet to live on, but eventually you start to get the hang of residing on it and may even enjoy it. To implement a GET we first create a web request and then call it. The web request is created with the the convenient WebRequestCreator. You can think of the WebRequestCreator as a factory that churns out HttpWebRequest objects. Just feed it a uri and out spills a web request. Keep in mind that you still need to populate the request with the methods, headers, and data. Once you have your web request ready, just call the asynchronous BeginGetResponse and wait. Listing 2 shows an example of creating the request and making the asynchronous call. Read more: C# Corner