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
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…
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.
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
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
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
Hi Sebastian and others I see, REST is something, one could spend a lot of time on discussing.
I would be happy with following solution.
1. 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) 2. allow to put complete description (not a reference) of execution context into request. 3. description of existing context parameters must go somewhere, to allow "follow your nose" paradigm 4. allow chaining queries and commands in one request 5. 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
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 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 querythen 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, 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
-- 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
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=...
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
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 executioncontext into request.
• description of existing context parameters must go somewhere, toallow "follow your nose" paradigm
• allow chaining queries and commands in one request • give up any attempt to reuse part of result of one query infollowing 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 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 querythen 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, mixingqueries and 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
-- 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
basex-talk@mailman.uni-konstanz.de
-
Jan Vlčinský (CAD) -
Sebastian Graf