We are designing a .NET Portal application requiring accessing a REST Web service outside our domain. "How should our developers handle this?" They are much better .NET developers than Javascript developers. So I performed some research and found a nice article. It is posted here for our reference only. We didn't write this REST Web Service article, but I want to refer to it when discussing with our client the pros & cons of consuming the REST Web Service. To see the REST Web Service article in its natural form, go to http://thenewblack.sirotamail.com/2007/09/rest-web-service-call-client-vs-server.html
The following comes from the REST Web Service article.
My company is integrating with a 3rd party website that will provide Event and Calendar widgets. The data is accessible to us through a REST interface, basically XML over HTTP. A sample call might include:
http://domain.com/events/search?start_date=8/30/2007
This would return XML that looks like this:
<events>
<event>
<title>Mommy & Me</title>
<start_date>8/30/2007 10:00</start_date>
<end_date>8/30/2007 11:00</end_date>
</event>
<event>
<title>Mommy & Me</title>
<start_date>8/30/2007 10:00</start_date>
<end_date>8/30/2007 11:00</end_date>
</event>
</events>
We’ve been going back and forth about whether to make the call and parse the data on the client-side or the server-side.
If we did it on the server-side, we’d use .NET’s WebRequest object and deserialize the XML into .NET objects: Event, List<Event>. Then bind the data to the ASP.NET controls on the page.
If we did it on the client-side, we’d use a XMLHttpRequest, then a JavaScript XML toolkit to deserialize the XML into JavaScript objects and set the values on the client side like this:
event = [javascript object]
div = document.getElementById(divId)
if(div) { div.innerText = event.start_date; }
etc…
There are pluses and minuses to both methods, detailed here:
| Server-Side |
Client-side |
| Too Many HTTP Connections can clog up the server |
HTTP burden is on the client computer |
| Can utilize built in data manipulation tools such as Sorting, Filtering, Pagination |
Team would have to either write custom code or use 3rd party javacript to do data manipulation |
| Easier to utilize built-in ASP.NET controls (such as Calendar) without passing ClientIDs to Javascript |
Easier to widgitize JavaScript libraries using DHTML for publishing to other sites (a la Google Maps) |
| Facilitates Caching of Requested Data on the Web Server |
Caching is less important because data is retrieved and stored on the client |
| Debugging, IDE tools are sophisticated in .NET |
Visual Studio 2008 has much better support for JavaScript debugging and FireFox plugins make coding in JavaScript easier than it used to be. |
| .NET has built-in toolkits for XML deserialization, JSON is not used as much with .NET. |
JavaScript can work well with JSON (which the web service supports) and XML |
| Our programmers tend to know more about .NET than JavaScript |
Ajax is the new black |
If it weren’t for HTTP Connection load, my choice would clearly be Server-Side, but given that doing real-time queries on a web server can be resource-intensive, would we be painting ourselves into a corner performance-wise if we forced the web server to retrieve the data from the API?
***********************************
Finally, the author provides an update on his REST Web service choice.
UPDATE: it turns out that due to cross-site scripting attacks, most common browser settings don't allow you to call a cross-domain web service directly from javascript using XMLHttpRequest
That means that in order to do the request client side, either the web service company has to provide the javascript as a <script src=> or you have to wrap the web service on the server, which defeats the performance gains.
Server-side it is!