[fpc-pascal] Troubles with SQLDBRESTBridge

[Sven Barth]

Am 22.06.2019 um 10:30 schrieb Michael Van Canneyt:
>
>
> On Fri, 21 Jun 2019, Sven Barth via fpc-pascal wrote:
>
>> Hello together!
>>
>> I've played around a bit with the SQLDBRESTBridge and encountered some
>> troubles which I wanted to check up here on the list whether those are
>> indeed bugs or not before reporting them to Mantis.
>>

First of thanks for applying some of the patches and explaining the 
problems with the others. However see below.

>>
>> So I started to research what went wrong and found various points:
>> - the metadata was coupled with the rdoConnectionInURL flag in
>> TSQLDBRestDispatcher.DoRegisterRoutes instead of rdoExposeMetadata (see
>> patch exposematadata.patch)
>
> This is not quite correct. The rdoConnectionInURL check is also 
> necessary:
>
> Both connection/metadata and /metadata must work.
>
> connection/metadata is handled by HandleRequest (FindSpecialResource)
> So a special registration for metadata must be handled here.
>
> But there was indeed a bug in the code, I fixed it properly.

Ah, now I get the intention. :)

>
>> - then it turned out that the routes are only registered once the module
>> was loaded and thus they would never be found so I adjusted
>> TSQLDBRestModule.HandleRequest to call the router again (this of course
>> required to change the BasePath of the TSQLDBDispatcher in the example
>> to 'REST' instead of '') (see patch reroute.patch) - this point I'm
>> definitely not sure whether it is the right solution (but in the end it
>> works)
>
> This is not the correct solution.
>
> The module itself handles the routes: the module is
> registered e.g. under /REST and then the request is dispatched to the
> router, and the dispatcher will take care of the rest.
>
> This means of course that when you use a restmodule, the dispatcher
> 'RegisterRoutes' must not be called at all, and this can be achieved by
> setting Active to False.
>
> Maybe the meaning of active is a bit obtuse. I put a comment in when I 
> made
> it, but if that goes unnoticed...
>
> In general, I added the rest module only for completeness. I think the
> simple datamodule approach (as demoed in restbridge demo) is the 
> better way:
> this keeps the schema in memory. for cases where you want to control the
> connections through the REST api, this is needed anyway.
>
> 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)

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).

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...

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:
- localhost:8080/metadata works
- localhost:8080/users returns "INVALID RESOURCE"
- 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? Btw: is it by intention that the 
call to CheckOptions does not contain 's'/'ssl'?)

Here is the output (I first tried "localhost:8080/metadata" and then 
"localhost:8080/users"):

=== output begin ===

[HTTP] From: 127.0.0.1; URL: /metadata
[Resource] (User: ?) Resource: metadata; Operation: GET
[Connection] (User: ?) Using connection to Host: ; Database: expenses.db
[Result] (User: ?) Resource: metadata; Operation: GET; Status: 200; Text: OK
[Result] (User: ?) Resource: ?; Operation: GET; Status: 404; Text: 
INVALID RESOURCE

=== output end ===

And yes, the JSON and Buf clients don't work either with that server 
example...

>
>>
>> I haven't tested more yet, so I don't know whether there are any further
>> problems. :)
>
> Well, I yesterday created a demo for TMS Software's TMS Web core using 
> the SQLDB Rest bridge as a backend, so I'm pretty sure it works 99%. 
> They will include a component that can be dropped on a web form which 
> will allow you to enter SQL etc.
>
> With your patches, we got closer to 100%, so many thanks for that !! :-)
>

Considering that I plan/want to use the SQLDB REST Bridge for a project 
of my own of course I want it to work correctly. ;)

Regards,
Sven