With AIP-162 moving towards a new design that is incompatible with the previous (known as "legacy" from here on), the same rules for List Revisions APIs no longer apply, and directly conflict with Standard List APIs. All of the legacy list revisions rules are deleted.
Now, instead of excluding List{Resource}Revisions methods from the scope of Standard List methods, we will exclude legacy list revision methods from the scope of Standard List. Legacy methods are identified as follows:
having a method name Like List{Resource}Revisions
having a string name field instead of string parent
having the :listRevisions HTTP uri suffix
Note: If the RPC does not have a google.api.http binding to check for the suffix, fulfilling the first two aspects will be sufficient to identify a legacy method.
This means that all "new" list revisions methods will adhere to Standard List structure AIP-132.
With AIP-162 moving towards a new design that is incompatible with the previous (known as "legacy" from here on), the same rules for List Revisions APIs no longer apply, and directly conflict with Standard List APIs. All of the legacy list revisions rules are deleted.
Now, instead of excluding
List{Resource}Revisionsmethods from the scope of Standard List methods, we will exclude legacy list revision methods from the scope of Standard List. Legacy methods are identified as follows:List{Resource}Revisionsstring namefield instead ofstring parent:listRevisionsHTTP uri suffixNote: If the RPC does not have a
google.api.httpbinding to check for the suffix, fulfilling the first two aspects will be sufficient to identify a legacy method.This means that all "new" list revisions methods will adhere to Standard List structure AIP-132.
Addresses internal bug