In the GET call we can mention the required list of field names, including parent child hierarchies.
GET /resource?fields=field1, field3, parent1.child2
Here additional effort is fields list has to be parsed and each field need to be mapped to DB Entity field. For this simple convention is you can use same field names as in DB Entity class in above GET request.
In some cases fields list in GET call may be too many and exceed the allowable URL size then profiles or views approach can be used. A
named view consists of predefined list of fields, so each view name defines a
unique list of fields. Let’s say for discussion, our views are AsiaPac
(consists of 20 fields), Euro (consists of 40 fields), Australia (consists of
30 fields) etc, i.e. unique list of Resource fields are tied to each view name
based on the relevance; now if I request for AsiaPac view then I would be given
20 fields, for Euro 40 fields and for Australia 30 fields. So my API usage can
be
GET resource/123?viewName=Euro
