26 Feb
2011
26 Feb
'11
10:44 a.m.
Hi Sebastian I also find the Christians proposal good one. In fact - his proposal is pivot of our discussion where we just keep looking around for other options while sitting on it. Have a nice weekend too. Jan 2011/2/26 Sebastian Graf <Sebastian.Graf@uni-konstanz.de> > Hi Jan, > > > Hi Sebastian and others > > I see, REST is something, one could spend a lot of time on discussing. > As on everything;-)…somehow > > > > > I would be happy with following solution. > > • make clear, what are attributes of context we need for executing > a query or command > > (what database is open, if any, what is timeout, other can be found, but > not too many) > > • allow to put complete description (not a reference) of execution > context into request. > > • description of existing context parameters must go somewhere, to > allow "follow your nose" paradigm > > • allow chaining queries and commands in one request > > • give up any attempt to reuse part of result of one query in > following commands or queries within one request > > (of course, if a query modifies a resource, following queries and > commands will be using it in the new state) > > I see, that at the moment we try to do some optimization (minimizing > amount of transferred data by storing it temporary on the server, bundling > too many queries and commands in one batch saving requests by somehow > linking results to following parts) we end up too easily not being RESTfull. > > > > Jan > I nevertheless find Christians approach very practicable since it > - does not restrict former functionalities > - does not rely on any states > > More concise: Points 1-3 are easily manageable within "fat" requests where > all information is stored within such. > Point 4 represents the challenge…it's a question of the architecture: If > you rely on any states regarding the server you can rely on thinner client > functionality. > Point 5 represents the main aspect of REST: Are you willing to give up any > states within any communication (which switches the effort for providing > integrity-ensured requests from the communication layer to the application > layer)? > Your assumption is completely right. RESTful services bring a high > flexibility which comes at a price (which is very often > forgotton…unfortunately). > > enjoy your weekend > > sebastian > > Am 25.02.2011 um 17:29 schrieb Jan Vlčinský (CAD): > > > > > 2011/2/25 Sebastian Graf <Sebastian.Graf@uni-konstanz.de> > > 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=1&command=info > > > > > > > > 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 > > > > _______________________________________________ > > 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