[fpc-pascal] Troubles with SQLDBRESTBridge
Michael Van Canneyt
michael at freepascal.org
Sun Jun 23 00:50:56 CEST 2019
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 ? :)
>
> 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;
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.
>
> And regarding the comment of TSQLDBRestDispatcher.Active:
> - first of I simply expected the example to work as is, so I definitely
> didn't look at any comments
> - "Register or unregister HTTP routes" doesn't really say much and in
> what situations it should be used...
Correct.
>
> Also I've tested the restbridge example provided with Lazarus. It works
> better (after fixing a compilation error in restserver.lpr at line 59
> where "Header:=Header+'; Using SSL');" should be "Header:=Header+';
> Using SSL';"), but not correctly either:
Ah, I will check that. I compile using 3.0.4 mostly. (to make sure that
works)
> - localhost:8080/metadata works
> - localhost:8080/users returns "INVALID RESOURCE"
Because it has rdoConnectionInURL set, and so you must do
localhost:8080/expenses/users
> - and for some reason it prints that it's using SSL, but the 's'/'ssl'
> option isn't provided... :/ (ah, I just noticed why:
> TCustomHTTPApplication.GetUseSSL is empty :/ - probably should contain
> "Result:=HTTPHandler.UseSSL;" instead?
Fixed.
> Btw: is it by intention that the
> call to CheckOptions does not contain 's'/'ssl'?)
>
Oversight, fixed.
> Here is the output (I first tried "localhost:8080/metadata" and then
> "localhost:8080/users"):
As said, the latter must be localhost:8080/expenses/users
Michael.
More information about the fpc-pascal
mailing list