Update AIP-151 with a validation-only LRO pattern.

Author: jskeet

aip/general/0151.md

@@ -59,6 +59,22 @@ rpc CreateBook(CreateBookRequest) returns (google.longrunning.Operation) {
 - APIs with messages that return `Operation` **must** implement the
   [`Operations`][lro] service. Individual APIs **must not** define their own
   interfaces for long-running operations to avoid non-uniformity.
+- If an RPC supports a [validate-only mode](aip-163), the response to a
+  validation request **must** be one of the following:
+  - A successful response with an `Operation` which is already complete, with
+    the `done` field set to `true`, and a valid (but potentially empty) response
+    message in the `response` field, wrapped in a `google.protobuf.Any` message.
+    The `name` field **may** be empty, to avoid the service having to maintain
+    state for successful validation.
+  - An immediate error response (typically "bad request")
+  - An `Operation` with the `done` field set to `false`, to indicate
+    long-running validation. In this case, the `name` field **must** be set,
+    to allow clients to poll the long-running validation operation until it
+    has completed. Successful validation **must** eventually be represented by
+    an operation with `done=true` and a valid (but potentially empty) wrapped
+    response message in the `response` field. Unsuccessful validation **must**
+    eventually be represented by an operation with `done=true` and the error
+    details provided in the `error` field.
 
 **Note:** User expectations can vary on what is considered "a significant
 amount of time" depending on what work is being done. A good rule of thumb is
@@ -113,13 +129,30 @@ metadata message. The errors themselves **must** still be represented with a
 Changing either the `response_type` or `metadata_type` of a long-running operation
 is a breaking change.
 
+## Rationale
+
+### Validate-only behavior
+
+The guidance for validate-only responses comes from a tension
+between clients, which benefit from "fully formed" operations that can
+be treated uniformly, and servers, which don't wish to maintain
+additional state for trivial operations. It seems counterintuitive
+that just validating a request should generate more state, but a
+full operation response that can be fetched later would either
+require that or "special" singleton operation IDs. The guidance
+provided is a compromise: by returning a "done" operation, clients
+can use existing logic to check that the operation has completed
+successfully (and therefore doesn't need to be fetched for an
+updated status) but server don't need to maintain any additional state.
+
 <!-- prettier-ignore-start -->
 [aip-128]: ./0128.md
 [aip-131]: ./0131.md
 [aip-132]: ./0132.md
 [aip-133]: ./0133.md
 [aip-134]: ./0134.md
 [aip-135]: ./0135.md
+[aip-163]: ./0163.md
 [aip-193]: ./0193.md
 [aip-216]: ./0216.md
 [google.rpc.Status]: https://github.com/googleapis/googleapis/blob/master/google/rpc/status.proto
@@ -130,7 +163,9 @@ is a breaking change.
 
 ## Changelog
 
-- **2022-06-??**: Added compatibility section
+- **2024-04-23**: Provided pattern for validation on RPCs returning
+  long-running operations.
+- **2022-05-31**: Added compatibility section.
 - **2020-08-24**: Clarified that responses are not streaming responses.
 - **2020-06-24**: Added guidance for parallel operations.
 - **2020-03-20**: Clarified that both `response_type` and `metadata_type` are