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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
