Hey all,
Am 25.02.2011 um 11:25 schrieb Jan Vlčinský (CAD):
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).
This would not be RESTful. RESTful inherits the stateless paradigm which would be violated with any session handling. What you can do is to project the "session" on an own defined resource which represents a temporary resource. With defined authorization, this is what comes next to a session handling.
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.
If such a transfer takes place assuming knowledge on the server side, this knowledge must be represented over a resource to satisfy the stateless paradigm. Assuming consecutive behavior on the server is not stateless otherwise.
However, this is rarely strict and of course the access over URI with the help of http-verbs can be flexible adapted to your own need.
cheers
sebastian
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 breaking compatibility • 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 be updated 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 be updated 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 then risking 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, which cannot 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 queries and commands • Possible problems • compatibility with existing design • wish to pass query result into next command/query
2011/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?query=1&query=2 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
-- 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