Dear Christian,
using rest:uri() and a bit of tokenizing did the job, but it feels not right, that "test/a;c=3/b;x=y/c;d=4;y=3/x" would trigger %rest:path("/test/{$param1}"). This call should trigger %rest:path("/test/{$param1}/{$param2}/{$param3}/{$param4}"). You can still get the complete uri with rest:uri() and process it correct manually, but I'd call that a work around.
At least for the implementation of RestXQ the uri shouldn't be cut at the first ';'. It leaves me wondering, that rest:uri() is able to print the complete path, but the function call is limited to a shredded path.
Nevertheless – for the moment it works, I'm fine :-)
Thanks a lot Peter
-----Ursprüngliche Nachricht----- Von: Christian Grün [mailto:christian.gruen@gmail.com] Gesendet: Dienstag, 11. April 2017 10:25 An: Peter Hinkelmanns mailinglists@hinkelmanns.de Cc: BaseX basex-talk@mailman.uni-konstanz.de Betreff: Re: [basex-talk] RESTXQ and URI-Parameters
I noticed there is at least one way to get hold of the matrix parameters: You can use the rest:uri() function [1].
You need to import the corresponding namespace, otherwise the function will not be detected:
import module namespace rest = "http://exquery.org/ns/restxq"; declare %rest:path("{$dummy=.+}") function local:f($dummy) { rest:uri() };
Hope this helps, Christian
[1] http://docs.basex.org/wiki/RESTXQ_Module#rest:uri
On Tue, Apr 11, 2017 at 9:57 AM, Christian Grün christian.gruen@gmail.com wrote:
Dear Peter,
I had a quick look into our implementation, and I noticed that our RESTXQ code relies on a default Java servlet method to retrieve the path of a URL [1]: For your example, it returns "4/test/a/b" and skips everything after the semicolon.
In the RESTXQ spec, we haven’t really specified what a "path" and corresponding "path segments" are. Maybe we won’t lose anything if we include a custom way to parse paths. On the other hand, I imagine it could be more consistent if we did it the same way as it is done in JAXRS, which provides a @rest:matrix-param annotation. The drawback here is that it won’t be possible to associate the matrix parameters with the original path segments (or, depending on the implementation, only the last path segment will be checked for matrix parameters).
As I just see, problems with missing matrix parameters, and custom parsing of URL paths have already been discussed for Apache-CXF [2]. RESTEasy seems to have a custom uri info implementation [3].
I have two questions on eXist-db: • Do you know if matrix parameters are automatically decoded? • I assume that paths are currently not decoded at all? Here are some examples how path are currently decoded by our implementation:
– "/test/a%20b/c" → "/test/a b/c" – "/test/1%2f2" → "/test/1/2" – "/test/a%3bb=c" → "/test/a;b=c"
We could think about completely getting rid of path decoding; but we’d first need to understand how this affects existing applications. As far as I can judge, there is no canonical way of what a web server does here: On some web sites, I can replace slashes in the URL with %2f, in others, I get 404.
All feedback is appreciated.
Cheers, Christian
[1] https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/o rg/basex/http/HTTPConnection.java#L77 [2] https://issues.apache.org/jira/browse/CXF-3403 [3] https://docs.jboss.org/resteasy/docs/1.0.0.GA/javadocs/org/jboss/reste asy/specimpl/UriInfoImpl.html
On Mon, Apr 10, 2017 at 11:10 AM, Peter Hinkelmanns mailinglists@hinkelmanns.de wrote:
Dear all,
I noticed, that the implementation of RestXQ in BaseX behaves differently compared to the implemation in eXist.
If you have a simple API like
declare %rest:path("/test/{$params1}/{$params2}") %rest:GET function test($params1 as xs:string*, $params2 as xs:string*) {
<response> <p1>{$params1}</p1> <p2>{$params2}</p2> </response> };
And you call this Uri "/test/a/b;c=2"
BaseX returns
<response> <p1>a</p1> <p2>b</p2> </response>
versus the response of eXist
<response> <p1>a</p1> <p2>b;c=2</p2> </response>
--> It seems to be not possible to pass Matrix URIs in BaseX over --> RestXQ right now.
eXist would accept as well a call like "test/a;e;f=5/b;c=2". BaseX passes out at this point, because nothing after the first ; is evaluated and thus no matching RestXQ API can be found.
My questions: -Is this a bug? -Is there a feature missing in the current implementation of RestXQ in BaseX? -Or is there an easy configuration for BaseX available, which will allow working with Matrix-Uri-Parameters and RestXQ?
Thanks and bye Peter