Our resources consists of dozens of fields (attributes). Some of our clients don't need all resource's properties. To save network payload we implemented a query string parameter to limit the resource properties. So for example, the next URL will return a collection of resources with all their fields:
But when the client needs only specific fields he can do that by calling:
http://myapp/myresources?fields=f1,f2,f13,f22
Our architect argues that this approach is not RESTful.
What do you think?
It would be RESTful if you implemented it as new media types (representations) of the same resource. It would be an incomplete representation, but still, a representation. Let's say you have this resource:
/myapp/myresources
which is a collection of complete representations of some kind of resource. It's perfectly ok to have a different representation of the same collection. However, if you want it to be REST compliant, you should implement it as a new media type (format).
Then, you can query the collection with Accept header set to your desired media type, or you can use "media type in extension style" - eg. /myapp/myresources.f1_f2_f3.
Your situation is a bit tricky, since your media types would be invented on the fly, but I think it's not impossible.
The question goes away if you stop making the distinction between resources and fields.
If resource /myresource has two 'sub-resources' /myresource/f1 and /myresource/f2, then it makes sense to get both at once by specifying a list: /myresource/f1,f2.