Building RESTful Services with XQuery and XRX

By Kurt Cagle
January 23, 2009 | Comments: 12

I've been banging on the RESTful services/XRX bandwagon for a while now, and the good folks at O'Reilly have kindly consented to let me get out the entire trap drum set for an O'Reilly Webinar entitled "Building RESTful Services with XQuery and XRX".

For those of you unfamiliar with the the concepts, RESTful services are essentially a form of web services that take a very different approach to architecture from the traditional SOA-type services. They are built upon the idea of REST, and specifically around the idea that if you treat the web as a database of collections of documents (some real, some virtual) and use what amounts to a publishing or CRUD approach to accessing those documents, that you can in fact still create very rich applications that have the advantages of being easier to deploy, easier to manage, more scalable and in general simpler to use than both SOA and traditional web applications, while at the same time cutting down fairly dramatically on interdependencies and bottlenecks.

I'll be covering RESTful services in general and will demonstrate a simple RESTful service built around XQuery, REST and XForms as part of a 90 minute presentation on Wednesday, January 28 at 10am PST. Attendance is limited, so you'll need to register at http://oreilly.com/go/restfulservices. See you then!


You might also be interested in:

12 Comments

I saw the session yesterday and thought it was fantastic. Where can we go to download the sample code that you used?

Hi

I missed the event. Is there a downloadable recording of the event?

Yes, can we get the source code? Looked amazing. Can't wait to copy it :)

Source code and overview will be up tomorrow - I'm running a bit behind, but should have it ready by then.

Thank you for this very interesting presentation (I just looked at the YouTube video (the resolution is not good enough to actually read the source files...)).

I have some questions :

1) I am disturbed by the use of OpenSearch format for queries because of GET verb use. I would have use POST verb, instead, to be able to write search parameters with XML. Maybe a specific verb would be better ?

2) I don't see why it would also be good to have XQuery on client side

3) XForms doesn't include an XSLT capability for transformation. Do you think it should ?

Thank you again

Some good questions. Hopefully I'll have some good answers:

1) The use of open search there is something I've been toying with, but don't fully integrate yet. The idea is that the query code doesn't have to be XQuery predicates or sort routines (and there are some fairly compelling arguments that XQuery represents a security hole in that context), but that you do need to have some mechanism to indicate the acceptable notation for a query if it isn't in XQuery notation.

For instance, I might want to drop down to a termed search with syntax that looks like:

Gender:'Female';People:'Elf'

I'd use OpenSearch in this regard as a way of identifying the syntax and provide some documentation concerning the way that it is parsed. Of course, it may just be easier to include a documentation file with that same information - not sure yet on that.

As to the use of the XML search bundle, there are two approaches that you could take. One would be to send the XML as your query string (this works especially well in conjunction with XMLHttpRequest). This should only be done if the GET operation in question is idempotent - it doesn't change the state of the operation.

The second approach that you can take is a little more convoluted, but is more clearly RESTian. In that case, you POST the XML query (which would include a user defined key) to a specific seach collection, such as /characters/search. This would add the XML query to the queue of such searches, and would also launch as part of the pipeline for this search the requisite search based upon the XML.

The results of this (possibly with a wrapper), would then be placed on a /characters/search/result queue. Note in this case the queue would show only those particular items which were initiated by you (which would be established by an authentication sequence), and would include the user defined key as part of the result set.

This requires a little more work - you have to essentially retain the key then retrieve the content using that key (/characters/search/result/mykey) under a separate process - but the advantage is that you can batch multiple such searches. This can be especially useful when the query that you are performing may require asynchronous operations that may take minutes or even hours to perform, or that require some kind of human intervention (such as an approval process).

Additionally, you can use other asynchronous media, such as email or twitter, to notify you when your queries are complete, containing a link to the appropriate content.

2) XQuery on the client side makes sense in a number of contexts. For instance, you could use it as a replacement for DOM:

var results = XQuery("for $div in input()//div where $div/@class='content' and contains($div,'XQuery') return $div",document);
for each (var node in results){
   node.style.background-color='green';
   node.style.color='white;
   }

The above retrieves all div elements with class="content" and that contain the word "XQuery" in them and deposits them into an array. The next block then takes this and applies stylistic changes. You could even go one step further and define an external module called css that would let you update individual css attributes, in which case the above
could be rendered as:

XQuery("for $div in input()//div where
      $div/@class='content' and 
      contains($div,'XQuery') 
   return (
   css:set-value($div,'background-color','green'),
   css:set-value($div,'color','white'))",document);

Note that currently the XQuery() command does not exist, but here's two examples of how it would be used.

It also simplifies (or at least makes less confusing) XPath expressions, and makes it possible to replace nodes. The same concept could make parsing XML from XMLHttpRequest objects much easier.

3) What XForms needs (and what it has in XForms 1.1) is the option to support XPath 2.0, which in turn provides support for an extension mechanism. In that case, you could add XSLT support as a simple query call in an <xf:output> statement.

1) Could we compare REST verb with SQL commands this way :

REST GET verb is like SQL SELECT command,
REST POST verb is like SQL INSERT command,
REST DELETE verb is like SQL DELETE command,
REST PUT verb is some sort of SQL UPDATE command and
OpenSearch query string is like SQL WHERE clause

If so, is it correct that an OpenSearch query string can also be added to DELETE and PUT requests ?

Because relational databases have internal ids for each record ("ROWID" for ORACLE), would it be good for each POST request to return this kind of internal id ?

Considering procedures and functions can be defined in relational databases, is it a correct RESTian approach to define a specific collection of treatments and to POST treatment requests ? I think it could be a way to store pourcent of achievement, status, ...

2) Do you think XQuery could also be used within XForms ?

3) Do you think about a function like "xsl:transform(node, stylesheet-uri, parameters)" returning a text node or an element ?

Because XSLT stylesheets could also be in a collection, what about XHTML+XForms pages, CSS stylesheets,... ?

Thank you for your answers

1) Yes. I'll be exploring all of these topicas a little more in an article I'll be publishing today.

2) If you implement XPath 2.0 in XForms, then you've implemented a significant part of the XQuery functionality. My suspicion is that XForms 2.0 will likely represent the full merger of XForms and XQuery.

3) Typically, when XSLT is implemented as an XQuery extension, two functions are defined - one for returning documents, the other for returning streams, including text streams.

3a) Yes. Each of these are resources, and as such can (and for many reasons should) be stored in collections. Indeed, the idea of faces works quite effectively here - store CSS or script documents in an XML format, then generate the appropriate CSS or script output based upon the client capabilities.

Hi. Hate to be a pest, but is the source code up yet? Still don't see it anywhere.

Has the source, etc., been posted somewhere?

The source is coming - I was about ready to copy final code into a paper when my database went sideways, forcing me to rebuild some critical pieces. I hope to have it up soon.

hi,

I have read your presentation at Youtube, which is really interesting. I am evaluating a RESTful API. Here, a question in my mind is about the DELETE verb. I studied the RFC about HTTP DELETE command, which explains that the server moves the resource to an inaccessible location. Therefore, will there be a possibility that server confuses and returns that inaccessible recource, in responce to a GET request?
Thanks

PS: I really, wanted to download your, slides and source codes, that you mentioned during your presentation on youtube, unfortunately, I don't have access rights to your Event Center that i couldn't obtain them. Will you put them under GPL and easily access information about them please?

News Topics

Recommended for You

Got a Question?