You are not logged in.
Pages: 1
Hello friends
First of all congratulations for the work, I'm delighted with the possibilities.
I am studying the framework and developing a test project to run a RESTful server.
Well, going to the point, I have these two doubts that I could not solve via documentation or research in the forum. Sorry if it was already answered.
==============
1 . Is it possible to change the default behavior of the REST server published by ORM?
For example, when accessing /root/product all the ids of the Products table are listed.
I need only list the searched records, for example:
/root/product?category= 4
And that list the complete product data and not just the ID.
==============
2. Is it possible to remove attributes from the returned JSON, to hide sensitive data such as passwords?
Example: /root/user/1 returns
{
"ID": 1,
"Name": "Jhon",
"Password": "xyz": <- I Need to omit this property
}
Since RegisterCustomSerializerFieldNames and RegisterCustomSerializer... dont work with TSQLRecord classes, How could this be done?
==============
If this is not possible the only alternative would be through method-based services, since interface based services dont handle PUT, DELETE... verbs, correct?
In this case will I need to mimic all methods of ORM's REST implementation? Or I can change just what I need.
Example:
GET /root/product/1 -> Handled by default ORM Rest ...
GET /root/product -> Handled by method-based service to list complete product data, search, pagination, etc.
GET /root/user/1 -> Handled by method-based service to hide properties, etc.
POST /root/user -> Handled by default ORM Rest ...
Best Regards
Apo
Last edited by Apo (2019-05-02 22:09:28)
Offline
For 1. and 2. this is possible with defining your own REST service, either as interface or as method.
Interface could handle all verbs, from its ServiceCurrentContext thread variable.
But, indeed, method-based services are preferred in you need full access to the request parameters, and returned data.
You would rather have to "mimic" the ORM REST implementation - but it is a matter of a single method call, since it already handle JSON natively.
Offline
Thanks Arnaud, for the clarifications.
I think I understood all the points, and method-based really seems to be the best option.
Since the method name will be part of the uri, if I create a "apiv1" method, this one method will automatically receive all requests related to TSQRecord's registered.
So in the method I use Ctxt.Table and Ctxt.TableID to process as I need.
Perfect.
Offline
Pages: 1