You could, if you really want to, just pass the SQL query in as a GET parameter. You could also invent some mapping from SQL to a more traditional URL layout, but I would not recommend that either.
There are several rasons for this. One reason is that it's nice to be able to change the SQL and/or the underlying database structure without breaking lots of client implementations. Another reason is that exposing an SQL interface (translated or not) could inadvertently leave your application open to SQL injection attacks.
Usually, though, a service would be at a more coarse-grained level than a typical SQL query. The external interface should be in terms of consistent and complete domain items, not individual rows, columns or tables.
When I wrote webSQL, I didn't mean to expose an underlaying database. If there is some data structure (linked list), which is repesented by linked web pages (resources), then it will be great to be able to grab, say, two pages in the middle by some GETSql (instead of making a number of sequiential GETs). Does it make sense?
Vladimir, you can use HTTP pipelining (a feature of HTTP 1.1) to send batch GET and HEAD requests. You can also use Keep-Alive (another feature of HTTP 1.1) to make multiple HTTP requests without closing the TCP socket. Those optimizations should significantly cut down on your overhead. This is not covered in RWS, but HTTP: The Definitive Guide talks about it in chapter 4.
Joined: Jan 07, 1999
Originally posted by Vladimir Shcherbina: When I wrote webSQL, I didn't mean to expose an underlaying database. If there is some data structure (linked list), which is repesented by linked web pages (resources), then it will be great to be able to grab, say, two pages in the middle by some GETSql (instead of making a number of sequiential GETs). Does it make sense?
OK. I think I understand now. It's an interesting idea.
My gut feeling is that this is likely to be too application-specific for something as general as an SQL-equivanet query language.
I have found that several of the REST APIs I have designed have allowed room for multiple ids in the URL. For example:
might retrieve data about the products with the three ids in a single request, or:
might fetch the six products on the twelfth page.
These are still RESTful requests, just ones which return aggregated data.
Is that along the lines of what you were asking, or have I missed the point again?
Joined: Jan 07, 1999
Also, I have just remembered that I have successfully used XPath expressions in REST GET URLs to remotely query a large DOM object without needing to transfer the whole thing.
XPath might be a better fit than SQL if you are intending to query mostly tree-structured data.
Joined: Nov 15, 2005
Yes, this looks like a solution (especially XPATH). I need to read the book in order to understand what is the RESTful added value to HTTP.