Hi Disclaimers:
- I am not an REST expert, so feel free to correct me - My notes are just ides, not requests
Comments below.
2011/2/25 Sebastian Graf Sebastian.Graf@uni-konstanz.de
Hey all,
Imho, as long as the request itself stays atomic, nothing speaks against multiple definitions of the the request (which seems to be the case regarding Christians example).
I just got a discussion regarding something similar and we came to the point that another "REST-elegant" way would be to rely on the resource directly. That means that factbook in the example of Christian is represented by different resources which represent different "functionalities" or, in this example, "settings". I have to admit that this makes only sense regarding the consecutive usage of equal parameters. However, such resource-based queries are easily created within own defined PUT-requests which makes them somehow "persistent" at the server side. Just another solution even not practicable for every use case…
*Could we think of established session (what includes all the status of opened collection, settings for timeout etc.) as of a resource? It has to be maintained on server, but as long as we refer to it in url, we are still going REST style. I think your "settings" idea is just this (I would include in it all the context we need).*
Yet, I think the most practicable way would be to extend the current schema with additional "settings" regarding the POST which would solve most of the issues described by you, Jan. Furthermore it should clearly be distinguished between "safe query" based on GET and POST/PUT/DELETE from a REST point of view (even if this is not a trivial task regarding XQuery/Update, we already got our internal discussion on this).
I think the problems are easy to handle as long as we are only extending the current schema which should be possible.
However, the passing of a result to the next query/command must respect the stateless paradigm of REST that means that you shouldn't rely on already computed results / settings on the server side. Each request must be atomic and encapsulated even if some settings/results can be "stored" like in my example above and referable over an own resource. Nothing speaks against the encapsulating of the former result or the storing of the result in an own resource. But REST encourages you not rely on changes of the same resource within consecutive requests.
*Use case with passing results to the next query command was meant as example of possible wishes, which might arise. My idea was to pass somehow results between particular request queries and commands inside one request.* *Take it just as thinking one step further on. I consider it rather exotic at this moment and would not spend too much time on it.*
Hope that helps a little bit
regards
sebastian
Am 24.02.2011 um 22:08 schrieb Jan Vlčinský (CAD):
Hi Christian I did try to write my ideas, but landed at reading what is REST and what
not - and run out of time.
So here is draft of some of ideas - unfortunately without clear proposal
for next action, but someone will probably take it over and move on.
Jan
JAX-RX and BaseX • Aim • Summarize ideas and requests regarding JAX-RX interface
of BaseX database
• Topics • Mixing commands and queries in one request • Get and relevant post implementation without breakingcompatibility
• Are we REST like and do we need it? • What processing context we need • Typical Use Cases • Add document(s) and optimize • why • Want to be sure, that indexes will beupdated after collection has been modified and no one will have a chance to run a query on not optimized collection
• Updating query and optimize • why • Want to be sure, that indexes will beupdated after collection has been modified and no one will have a chance to run a query on not optimized collection
• Query with client defined timeout • why • It is better to quit too long query thenrisking that one too expensive query would endanger overall server performance
There is no need to get query results too late, when our http connection
already timed out
• Set of independent simple expression queries • Mix updating and simple expression queries • Set of independent commands • why • Needing to run a batch of tasks, whichcannot be interrupted by other clients
• Ideas • add timeout parameter to each request • check, what other timeout-like parameters we may need • introduce new request element for POST, mixing queriesand commands
• Possible problems • compatibility with existing design • wish to pass query result into next command/query2011/2/24 Christian Grün christian.gruen@gmail.com
OK, I understand, that REST allows to perform the (SET) command, but to
use
it with a query, I have to send the query in another, following,
request.
Will this second request keep enough context at the server side to
know, it
shall use that timeout?
Just recently, I've thought about extending the JAX-RX Interface to allow more than a single query or command, or to allow both commands and queries; regarding the syntax, this could be easily realized for the GET method:
http://localhost:8984/basex/jax-rx/factbook?command=set+timeout+1&query=...
On the other hand, I haven't decided yet how to best realize it for the POST method without giving up compatibility. One solution could be to introduce alternative "request" root elements:
<request xmlns="http://jax-rx.sourceforge.net"> <command> <text>set timeout 1</text> </command> <query> <text>//name</text> <parameter name="count" value="5"/> </query> </request>
What does everyone think? Christian _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
-- Ing. Jan Vlčinský CAD programy Slunečnicová 338/3, 734 01 Karviná Ráj, Czech Republic tel: +420-597 602 024; mob: +420-608 979 040 skype: janvlcinsky; GoogleTalk: jan.vlcinsky@gmail.com http://cz.linkedin.com/in/vlcinsky
Sebastian Graf Distributed Systems Group Department of Computer and Information Science University of Konstanz Phone: +49 7531 88 4319 Mail: sebastian.graf@uni-konstanz.de