feat(proto,operation): add operations service #23
Conversation
Operations service was not added in a previous commit. Having the service makes it easier to implement against the spec in consumers (like aepc).
| // server doesn't support this method, it returns `UNIMPLEMENTED`. | ||
| rpc ListOperations(ListOperationsRequest) returns (ListOperationsResponse) { | ||
| option (google.api.http) = { | ||
| get: "/v1/{name=operations}" |
There was a problem hiding this comment.
thought: Have we encoded the operations URLs in the AEPs anywhere?
At some point we'll either need a way for tooling to either know where operations live (always at /operations) or a way for them to parse the OpenAPI spec to figure out where they live.
There was a problem hiding this comment.
I think that should be provided as part of the response of the original LRO. The path is returned in the object: https://buf.build/aep/api/docs/main:aep.api#aep.api.Operation (one nice thing about the ref-like properties it provides).
So you use that resource path (mounted on the same API, or perhaps available as a full resource name).
| option (google.api.method_signature) = "name"; | ||
| } | ||
|
|
||
| // Deletes a long-running operation. This method indicates that the client is |
There was a problem hiding this comment.
It seems to me that deleting an operation should be the same as canceling it.
Otherwise, deleting the operation seems like a strange action for a user to take.
There was a problem hiding this comment.
agreed it's a weird one - maybe @rofrankel has an opinion?
I'm leaning toward keeping the RPC, but leaving the guidance that it can be unsupported and just return "UNIMPLEMENTED". In our case, as you mentioned, I think we'd want to use Cancel
2 participants
Operations service was not added in a previous commit. Having the service makes it easier to implement against the spec in consumers (like aepc).