From: Andrzej J. T. <an...@ch...> - 2010-09-23 15:40:57
|
Wolfgang said: > The request will be handled by the REST servlet, whose default > behaviour for PUT is to replace the resource at the given address. > > We could easily disable this behaviour for all XQuery resources and > let the query handle the request. However, a client application may > also need to actually replace the XQuery itself. This is a problem > since we plan to make the REST interface the main interface into eXist > for the future. So there has to be a way to distinguish between > requests, which call an XQuery on the server and those which want to > update or delete an XQuery resource. I'm not sure how to do this. Use > a parameter? A request attribute passed in from the url rewriting? > Suggestions welcome. The problem with using a parameter is that it could easily conflict with parameters being passed into the XQuery/Application. Why not instead just use a different URL designator other than REST for client applications that want to handle PUT/et al in their XQueries? For example a PUT to http://localhost/rest/db/myapp/myquery.xql.... would replace the myquery.xql While a PUT to http://localhost/xquery/db/myapp/myquery.xql.... would execute the xquery myquery.xql and let the xquery handle the put. It would require a different servlet...say an XQueryExecutionServlet or some such, but that is simple to accomplish, and common code could be shared by using a common base class between the new servlet and RESTServlet. This approach would be clean, simple and easy to implement without the chance of query parameter conflicts. The url designator could be something other than "xquery" as per my example above. Could be "application" or "execute" or whatever....so long as it's different from "rest". My 2 cents worth. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Anton K. <ak...@de...> - 2010-09-23 20:22:29
|
+1 user vote for second serlvet (sharing common base code with EXistServlet) On 23.09.2010 18:40, Andrzej Jan Taramina wrote: > Wolfgang said: > >> The request will be handled by the REST servlet, whose default >> behaviour for PUT is to replace the resource at the given address. >> >> We could easily disable this behaviour for all XQuery resources and >> let the query handle the request. However, a client application may >> also need to actually replace the XQuery itself. This is a problem >> since we plan to make the REST interface the main interface into eXist >> for the future. So there has to be a way to distinguish between >> requests, which call an XQuery on the server and those which want to >> update or delete an XQuery resource. I'm not sure how to do this. Use >> a parameter? A request attribute passed in from the url rewriting? >> Suggestions welcome. > > The problem with using a parameter is that it could easily conflict with parameters being passed into the > XQuery/Application. > > Why not instead just use a different URL designator other than REST for client applications that want to handle PUT/et > al in their XQueries? > > For example a PUT to http://localhost/rest/db/myapp/myquery.xql.... would replace the myquery.xql > > While a PUT to http://localhost/xquery/db/myapp/myquery.xql.... would execute the xquery myquery.xql and let the xquery > handle the put. > > It would require a different servlet...say an XQueryExecutionServlet or some such, but that is simple to accomplish, and > common code could be shared by using a common base class between the new servlet and RESTServlet. > > This approach would be clean, simple and easy to implement without the chance of query parameter conflicts. > > The url designator could be something other than "xquery" as per my example above. Could be "application" or "execute" > or whatever....so long as it's different from "rest". > > My 2 cents worth. > |
From: Hungerburg <pc...@my...> - 2010-09-24 09:36:52
|
Am 2010-09-23 22:13, schrieb Anton Kolev: > +1 user vote for second serlvet (sharing common base code with EXistServlet) >> >> Why not instead just use a different URL designator other than REST for client applications that want to handle PUT/et >> al in their XQueries? >> >> For example a PUT to http://localhost/rest/db/myapp/myquery.xql.... would replace the myquery.xql >> >> While a PUT to http://localhost/xquery/db/myapp/myquery.xql.... would execute the xquery myquery.xql and let the xquery >> handle the put. >> I am interested in handling PUT too. Triggers are only good for limited uses, so the possibility to map PUT to a controller is welcome. Yet: Handling PUT this way mostly makes sense with rewriting, i.e. if you want to hide the implementation from the interface. But then, there is no sense in exposing the functionality in the public interface at all. With the exception of examining PATHINFO in the handler: eg. PUT to http://localhost/rest/db/some.xql/data/new.xml Maybe it was enough, if the REST servlet itself, just like it does with GET requests, could test for pathinfo, and if present, would call the script, otherwise try and replace? Success will of course depend on permissions of the resource and authorization of the logged on user... -- peter |