XQuery Examples

SELECT AtosEPIXml1.query('
for $x in /ROOT/Description
where $x/Element_ID = 80168
order by $x/Element_Name

  • {data($x/Element_Name)}

    AS ElementName

REST Server or Client-side Web Service Calls

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:


This would return XML that looks like this:

<title>Mommy & Me</title>
<start_date>8/30/2007 10:00</start_date>
<end_date>8/30/2007 11:00</end_date>
<title>Mommy & Me</title>
<start_date>8/30/2007 10:00</start_date>
<end_date>8/30/2007 11:00</end_date>

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; }

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!