Hi Christian and Dirk,
Nothing major but I was wondering what the thinking was behind returning a 400 when fn:error is raised. Basically that says "client, your mistake not mine" where in most cases I guess a 500 would be more appropriate.
The rationale behind this was that a RESTXQ developer can use fn:error functions, which are triggered when the client sends invalid input. But it's true that 500 codes may be more appropriate if the server code is buggy indeed.
Thanks to Dirk I now know that I can specify response status through the third argument. I assume as I haven't tried it yet. But yes, I still think that assuming the code is wrong would be the better default. Not a biggie though :)
Of course I can always catch at the highest level and then decide which HTTP status to return but I'm not sure if I want to wrap all REST calls in try / catch.
Could you write more about your use case? Do you expect your code to be buggy, or when do errors occur?
I was fixing an issue on a REST API for one of our products that uses bx as an object cache. We had cases where a nested object was just added in the main app and bx would not be 100% up to date yet. When such a cache miss occurs I need to call into the main app's API to give me the missing object. This is done via http:send-request to the main app which obviously may fail in various ways too. I use fn:error to signal these conditions. Most of the RESTXQ functions deal with the same object querying and until now I just let the errors bubble up taking advantage of default behaviour. That's where I wanted to let the client know that the request wasn't successful (hence a 500). Probably a bit lazy. Does that make sense? I'm even older ;)
btw did you already give your Balisage presentation? I read your paper with great interest. Hope it was well received.
Gruß
--Marc