On Sun, 23 Jun 2019, Sven Barth via fpc-pascal wrote:
Okay, independently of whether the REST module is the optimal
solution or not, it should work, right? (and shouldn't the Wiki entry
then mention the advantages/disadvantages of the two approaches?
Cause when looking at the SQLDB REST module I thought "yay, less
stuff to configure" and rolled with that)
What exactly is less to configure ? :)
Looking at the Wiki again I was fooled by the Datamodule having 8 bullet
points, the SQLDBRestModule having 5, but the later simply shortening
stuff with point five... So yeah... not really less to configure... My
fault. ^^'
It's OK. I will try to document it a little better.
Cause with the changes you committed the example provided with
Lazarus still does not work (even if I change MyDispatcher.Active to
False and MyDispatcher.BasePath to 'REST'). The error is always
"INVALID RESOURCE" which means that ExtractRestResourceName returned
an empty string (which is logical, cause there neither exists a route
that sets 'resource' nor is HandleMetadataRequest ever called).
Ah. Documentation issue.
If you use a restmodule, then I expect the resource to be provided using
?resourceParam=Name, not in the URL.
See
function TSQLDBRestDispatcher.ExtractRestResourceName(IO: TRestIO):
UTF8String;
Ah! But that isn't mentioned in the Wiki, right? Cause the Wiki only
mentioned the URL based stuff and thus I assumed the SQLDBRESTModule to
behave the same...
Well, ideally it would be so, and I think I have a way to do it without
additional options: the module can simply set the routing params before
calling HandleRequest.
By the way: I sometimes get a EStreamError *after* all data had been
sent to the client. I have not yet found a reproducible way for this...
Please make sure you have the latest version of everything: I had this a
couple of times in case of an error. I fixed all occurrences, I hope.
But if you find additional cases: let me know.
We can of course change that to try and look in the URL as well using
GetNextPathInfo on the request if the routes are not registered,
that should work.
But then it needs to be done early on in the HandleRequest because the
rdoInConnection needs to be observed, so the path can be read only
once. It will probably require a new rdoUseRequestPathInfo, which
could be set by
the restmodule... I will look at this.
Would at least be nice to not have to care how one needs to call the
server side...
I agree, see above :)
- localhost:8080/metadata works
- localhost:8080/users returns "INVALID RESOURCE"
Because it has rdoConnectionInURL set, and so you must do
localhost:8080/expenses/users
Ahhhhhh! Hadn't seen that this option is active... Okay, then it indeed
works as expected, both with and without rdoConnectionInURL.
By the way: I noticed a slight annoyance, but I don't know whether one
can really do something about that: When I set rdoConnectionInURL to
False inside the object inspector it turns on again, because
rdoConnectionResource is set. Took me a moment to look at the source
code to see that I need to disable rdoConnectionResource first. Don't
know what a better solution would be...
Funny you mention this, I was fooled myself yesterday, I also had to look in
the sources :(
One way would be to disable rdoConnectionResource if you disable
rdoConnectionInURL. I will add this.
Further thing I noticed when testing BufClient and CSVClient: Changing
the resource doesn't work there either. I don't get an exception like
with JSONClient, but simply nothing happens.
Strange. I will test the examples again. Thanks for pointing it out !
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
