New subject: BaseX question - Enhancing JAX-RX interface

24 Feb 2011

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

Re: [basex-talk] BaseX question - Enhancing JAX-RX interface

Jan Vlčinský (CAD)

Sebastian Graf

Jan Vlčinský (CAD)

Sebastian Graf

Jan Vlčinský (CAD)

Sebastian Graf

Jan Vlčinský (CAD)

tags

participants (2)