The fully qualified name of the interface which is included.
from field: string name = 1;
If non-empty specifies a path under which inherited HTTP paths are rooted.
from field: string root = 2;
Compare with a message of the same type.
Parse from binary data, merging fields.
Repeated fields are appended. Map entries are added, overwriting existing keys.
If a message field is already present, it will be merged with the new data.
Parse a message from a JSON value.
Parse a message from a JSON string.
Retrieve the MessageType of this message - a singleton that represents the protobuf message declaration and provides metadata for reflection- based operations.
Serialize the message to binary data.
Override for serialization behavior. This will be invoked when calling JSON.stringify on this message (i.e. JSON.stringify(msg)).
Note that this will not serialize google.protobuf.Any with a packed message because the protobuf JSON format specifies that it needs to be unpacked, and this is only possible with a type registry to look up the message type. As a result, attempting to serialize a message with this type will throw an Error.
This method is protected because you should not need to invoke it directly -- instead use JSON.stringify or toJsonString for stringified JSON. Alternatively, if actual JSON is desired, you should use toJson.
Serialize the message to a JSON string.
Generated using TypeDoc
Declares an API Interface to be included in this interface. The including interface must redeclare all the methods from the included interface, but documentation and options are inherited as follows:
If after comment and whitespace stripping, the documentation string of the redeclared method is empty, it will be inherited from the original method.
Each annotation belonging to the service config (http, visibility) which is not set in the redeclared method will be inherited.
If an http annotation is inherited, the path pattern will be modified as follows. Any version prefix will be replaced by the version of the including interface plus the [root] path if specified.
Example of a simple mixin:
Example of a mixin configuration:
The mixin construct implies that all methods in
AccessControlare also declared with same name and request/response types in
Storage. A documentation generator or annotation processor will see the effective
Storage.GetAclmethod after inheriting documentation and annotations as follows:
Note how the version in the path pattern changed from
rootfield in the mixin is specified, it should be a relative path under which inherited HTTP paths are placed. Example:
This implies the following inherited HTTP annotation:
from message google.protobuf.Mixin