Could a Spec be partial?

While continuing my attempt to resolve https://github.com/infinyon/fluvio/issues/1131 I have found another corner case (a bit similar to #90 ) - `MetadataClient` uses `Spec` as a specification for a resource and provides methods for different operations for resources covered by that specification. But that set of operation looks to be fixed while Kubernetes API has resources with different sets of operations supported. In this particular case I'm trying to find an equivalent to `kubectl auth can-i`, under the hood it uses https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#selfsubjectaccessreview-v1-authorization-k8s-io and this resource supports only one operation - Create. Is it expected for `MetadataClient` to be a superset of any operations which could be available for a resource and it's a responsibility for a user to use only correct ones? That sounds not very good in terms of type safety...
So at the moment I'm a bit stuck between 2 conflicting requirements:
* using a `Spec` for `SelfSubjectAccessReview` means providing too much functionality and for exampe `Status` for this resource makes no sense at all
* using a special method for this resource would mean that other resources could require the same which would lead to not very clean API

In the end it looks that API should be more granular than single `MetadataClient` and a `Spec` should define also operations which are available for a resource but that's just an idea and it's not clear if there could be a good implementation for this which will not lead to a combinatorial explosion somewhere or would require too many type annotations.
What could be a proper way to resolve this?

BTW The library doesn't have a lot of documentation so I'd like to ask one extra question - is there some concrete motivation for this set of crates instead of using `kube-rs`?