Pruning the response would help validate your response schema is correct and that is delivering what was promised.
But you're right, if you have version skew and the client is expecting something else then it's not much help.
You could do it client-side so that if the server adds an optional field the client would immediately prune it off. If it removes a field, it could fill it with a default. At a certain point too much skew will still break something, but that's probably what you want anyway.
You're misunderstanding. In GraphQL, the server prunes the response object. That is, the resolver method can return a "fat" object, but only the object pruned down to just the requested fields is returned over the wire.
It is an important security benefit, because one common attack vector is to see if you can trick a server method into returning additional privileged data (like detailed error responses).
hdjrudni|2 months ago
But you're right, if you have version skew and the client is expecting something else then it's not much help.
You could do it client-side so that if the server adds an optional field the client would immediately prune it off. If it removes a field, it could fill it with a default. At a certain point too much skew will still break something, but that's probably what you want anyway.
hn_throwaway_99|2 months ago
It is an important security benefit, because one common attack vector is to see if you can trick a server method into returning additional privileged data (like detailed error responses).
JAlexoid|2 months ago
Therefore requests between GQL and downstream services are travelling "over the wire" (though I don't see it as an issue)
Having REST apis that return only "fat" objects is really not the most secure way of designing APIs
fastball|2 months ago
Because if so that is no security benefit at all, because I can just... request the fat fields.