Be possible to customize entity fields that will go into the REST response without the need to create Struct.


It is very easy return a Entity as a answer of a REST API. But when I need to customize the output I need create an Struct. A great idea would be to enable and disable the fields that will respond directly to the output variable. This could also be used on other occasions to customize the SQL result set without having to use an advanced SQL object. This would also decrease and greatly the creation of Structs.

Created on 11 Apr 2018
Comments (4)

Why do you want to costumize the SQL result on a aggregate? The platform does this for you. 

Just use the fields you want and the platform will take care of that for you.

Also, having those disable fields, will eventually lead to a huge entity because you will "need one more field". And you can "disable that field by assigning it a default value.

Abílio Matos

Changed the category to Integration

Hello Abilio, the platform can only optimize SQL if the aggregate is in preparation and effectively connected to a TableRecords for example. Aggregates within APIs or Server Action this does not happen, you can confirm this in the best practices document, be careful if you think this is the behavior that is being adopted by the platform. When you says:

"Just use the fields you want and the platform will take care of that for you."

In many instances this does not happen. Associating a default value with the field will not remove it from the result, either in the REST API or in an aggregate, it will only send a default value. The entity can have several fields that should not appear in the API response, for example, control fields, tag fields, setup fields and others. Today the only way is to create a struct specifying what you want. In large projects you have hundreds of structures that would be eliminated if you could customize what fields you want and what names they too should take.

Hello Vasco this isn't about Integration, It was just an example.

In my experience, you almost always need more than one Entity in the Aggregate you base your response on, not to mention that you typically want to create Lists of Lists while an Aggregate output is always "flat".

Also, you may need different Attribute names in your REST response than in your Entity. Of course OS could add JSON parameters like is done for Structures, but that would complicate things even more (what if you'd want different names for different REST services?).

So I think the current situation is fine as it is.