In early API drafts we considered doing exactly this. The main argument against it was concern that Client would become cluttered. In addition to create/read/update/remove functions we would need similar functions to all operations: queries, (not yet implemented) search, permission handling and maybe for file access.

Also, we need to offer some way to monitor when individual requests finish or fail (even when multiple requests are happening concurrently). Without operation classes functions would either return some object similar to QNetworkReply that could be used to get finished/error signals or some request ID which then would be received in Client::operationFinished(id) and Client::operationError(id) signals. It was seen that with separate operation classes would be cleaner way to implement this request state signaling as well as operation type specific methods, properties and signals.