Hi Marco, an introductory question: what’s your particular reason for splitting the operation in two parts? Do you perform database updates in the pre-validation step?

...

It works nicely up to the access to the POST content which appears to be consumed defintely by the first function.

That’s right: POST bodies can only be consumed once. We could think about extending the rest:forward-Syntax in order to construct a new body, but that’s just an idea (and I’m not sure if this is supported by the Java request dispatcher).

Moreover there is no possibility of stating that the postbody may possibly be empty, is it?

This should generally be possible. I have tried the following RESTXQ function: declare %rest:path("/post") %rest:POST("{$x}") function rest:main($x) { $x }; It doesn’t trigger an error when calling it with: curl -XPOST -i "http://localhost:8984/post" Could you provide me with a little example of your code that causes the problem? Christian

Since I don't want to make everything "updating", because I dont want to introduce unnecessary synchronization, I'd like to just call the native functions through the forwarding mechanism passing ahead the POST content of the request and exploiting the nice declarative way of routing with parametric path annotations. […]

I guess I should spend more time on understanding your use case, but due to my lazyness, I’m just asking why you don’t directly call the functions instead of using redirects? À la… OLD: (: do all SOAP related work here :) <rest:forward>{ "test/impl" }</rest:forward> NEW: (: do all SOAP related work here :) soapskel:impl($postbody) If it makes sense.. Do you have an example that demonstrates why this isn’t possible?

According to the optionality of the postbody parameter it works when I call a RESTXQ function directly. It also works when forwarding if the orignal HTTP request doesn't have any postbody. But when the postbody is there in the original request, the subsequent function (where I forward to) yields the error.

I just tried your example with the following curl call. As expected, it returns nothing, but it doesn’t raise an error either:

curl -i -XPOST -d"<a/>" "localhost:8984/test" HTTP/1.1 200 OK Content-Type: application/xml; charset=UTF-8 Content-Length: 0 Server: Jetty(8.1.11.v20130520)

Do you see what I did wrong? Christian

Of course I'm also ready to accept architectural suggestions if this can satisfy my needs ;-)

Here is a code snippet that should reproduce the error on 7.7.2. Both the plain version plus the one that uses the session trick. Hope this helps. Regards.

module namespace soapskel = 'urn:myns'; import module namespace session = "http://basex.org/modules/session"; declare %rest:path("test") %rest:POST("{$postbody}") %output:method("xml") function soapskel:test($postbody){ (: do all SOAP related work here :) <rest:forward>{ "test/impl" }</rest:forward> }; declare %rest:path("test2") %rest:POST("{$postbody}") %output:method("xml") function soapskel:test2($postbody){ (: do all SOAP related work here :) let $id := (session:id(), session:set('data',$postbody)) return <rest:forward>{ "test/impl" }</rest:forward> }; declare %rest:path("test/impl") %rest:POST("{$postbody}") %output:method("xml") function soapskel:impl($postbody){ if (empty($postbody)) then session:get('data') else $postbody };

On 01/14/2014 01:38 PM, Christian Grün wrote:

Hi Marco,

an introductory question: what’s your particular reason for splitting the operation in two parts? Do you perform database updates in the pre-validation step?

It works nicely up to the access to the POST content which appears to be consumed defintely by the first function.

That’s right: POST bodies can only be consumed once. We could think about extending the rest:forward-Syntax in order to construct a new body, but that’s just an idea (and I’m not sure if this is supported by the Java request dispatcher).

Moreover there is no possibility of stating that the postbody may possibly be empty, is it?

This should generally be possible. I have tried the following RESTXQ function:

declare %rest:path("/post") %rest:POST("{$x}") function rest:main($x) { $x };

It doesn’t trigger an error when calling it with:

curl -XPOST -i "http://localhost:8984/post"

Could you provide me with a little example of your code that causes the problem? Christian

functions where few of them are updating and few are not. I necessarily have to declare the soap entry point as updating too. Thus introducing particular syntax like db:output or synchronizations in places where it's not supposed to be needed. Isn't it like that?

Yes, I think I see the point. I would like to get completely rid of the db:output statements, as it can statically be deteted if a query is updating or not anyway. XQuery Update 3.1 might provide some ways out of the current situation.

I think it depends on the content type. I'm trying with firefox poster and it works if I force application/x-www-form-urlencoded. Conversely it stops working with

curl -i -XPOST -d"<a/>" -H "Content-Type: application/xml; charset=UTF-8" "localhost:8984/test"

Ok. If it’s requests are sent without a content type, the received value could be cast to XML via fn:parse-xml; but that may not be helpful in your case. I’ll have some more thoughts if there are chances to also forward the request content. It may take while, though.. Christian

For our case study we fixed creating two bindings in the wsdl exporting two services one for the query only operations and the other for the updating operations. This implied the editing of two restxq entry points that are actually clones of each other except for the "updating" and "db:output" details. I already had a frontend service acting as a bridge but for deployment and manageability reasons I wanted to avoid this. I'm not very happy of having to change wsdls because this alters the views for the clients but I've no other solution yet. <forward> supporting post content would have been defintely the best solution. I still hope there will be a way of realizing it in the near future. Regards, Marco. On 19/01/2014 14:52, Carl Leitner wrote:

Hi, Just wanted to say that we have a very similar use case (though not SOAP) of a standard requiring having one endpoint to receive all incoming requests. Some of these requests are updating and some are not.

At the moment, it seems like the only solution will be to have two endpoints (one for updating, one for not) and another service sitting in-front of BaseX that peers into the incoming message to determine which ones are updating or not before forwarding them onto the correct service.

Should we go ahead and setup something like this? Or does anyone have a more elegant suggestion?

Cheers, -carl

On Jan 14, 2014, at 9:49 AM, Christian Grün <christian.gruen@gmail.com> wrote:

...

...

functions where few of them are updating and few are not. I necessarily have to declare the soap entry point as updating too. Thus introducing particular syntax like db:output or synchronizations in places where it's not supposed to be needed. Isn't it like that? Yes, I think I see the point. I would like to get completely rid of the db:output statements, as it can statically be deteted if a query is updating or not anyway. XQuery Update 3.1 might provide some ways out of the current situation.

...

I think it depends on the content type. I'm trying with firefox poster and it works if I force application/x-www-form-urlencoded. Conversely it stops working with

curl -i -XPOST -d"<a/>" -H "Content-Type: application/xml; charset=UTF-8" "localhost:8984/test" Ok. If it’s requests are sent without a content type, the received value could be cast to XML via fn:parse-xml; but that may not be helpful in your case.

I’ll have some more thoughts if there are chances to also forward the request content. It may take while, though..

Christian _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk