Am 23.06.2019 um 00:50 schrieb Michael Van Canneyt:
On Sat, 22 Jun 2019, Sven Barth via fpc-pascal wrote:
The REst Module has the additional disadvantage that you must have an
initial /REST/ or whatever part in your URL. With the dispatcher on a
datamodule, you can skip this if so desired...
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. ^^'
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...
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...
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...
- 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...
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.
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
