I was wondering if there was an example of a ServiceSource Autoquery where the returned Fields list is controlled within the service, for example as part of a permissions structure.
So a given user has the ability to call a service that has AQ support, but he does not have access to fields A, B, C, so the service implementation hides them, instead of requiring the querystring to send the field list.
I’m also wondering if there is an example (or if it’s even possible) for autoquery functionality to work on child collections that might be arbitrarily deep in the response object structure.
You could have a custom service implementation that returns a different data structure or hides values on the way out based on your requirements.
Not arbitrarily deep, not without your own service implementation supporting that. Can you give an example of you would envisage functionality like this would work or at least be used? Merging result sets might give you some of what you are looking for.
Trying to do information hiding within the same service is rarely a good idea, I’d recommend having different Role/Permission protected Services returning different response types so the API Service Contract is clear what each API Returns.
Agree with this in principle, however we’re trying to do a better job of centralizing “business logic” into the service layer for the version 2 of our API, and we consider authorization part of business logic. Creating alternate services would push business logic decisions to the UI developers.