evmos.proto.autogen.py.google.api
Classes
|
A custom pattern is used for defining custom HTTP verb. |
|
Defines the HTTP configuration for an API service. |
|
Message that represents an arbitrary HTTP body. |
|
|
- class evmos.proto.autogen.py.google.api.CustomHttpPattern(kind: str = <object object>, path: str = <object object>)[source]
Bases:
MessageA custom pattern is used for defining custom HTTP verb.
- class evmos.proto.autogen.py.google.api.Http(rules: ~typing.List[~evmos.proto.autogen.py.google.api.HttpRule] = <object object>, fully_decode_reserved_expansion: bool = <object object>)[source]
Bases:
MessageDefines the HTTP configuration for an API service. It contains a list of [HttpRule][google.api.HttpRule], each specifying the mapping of an RPC method to one or more HTTP REST API methods.
- fully_decode_reserved_expansion: bool = <object object>
When set to true, URL path parmeters will be fully URI-decoded except in cases of single segment matches in reserved expansion, where “%2F” will be left encoded. The default behavior is to not decode RFC 6570 reserved characters in multi segment matches.
- class evmos.proto.autogen.py.google.api.HttpBody(content_type: str = <object object>, data: bytes = <object object>, extensions: ~typing.List[~betterproto.lib.google.protobuf.Any] = <object object>)[source]
Bases:
MessageMessage that represents an arbitrary HTTP body. It should only be used for payload formats that can’t be represented as JSON, such as raw binary or an HTML page. This message can be used both in streaming and non-streaming API methods in the request as well as the response. It can be used as a top-level request field, which is convenient if one wants to extract parameters from either the URL or HTTP template into the request fields and also want access to the raw HTTP body. .. rubric:: Example message GetResourceRequest { // A unique request id. string request_id = 1; // The raw HTTP body is bound to this field. google.api.HttpBody http_body = 2; } service ResourceService { rpc GetResource(GetResourceRequest) returns (google.api.HttpBody); rpc UpdateResource(google.api.HttpBody) returns (google.protobuf.Empty); } Example with streaming methods: service CaldavService { rpc GetCalendar(stream google.api.HttpBody) returns (stream google.api.HttpBody); rpc UpdateCalendar(stream google.api.HttpBody) returns (stream google.api.HttpBody); } Use of this type only changes how the request and response bodies are handled, all other features will continue to work unchanged.
- class evmos.proto.autogen.py.google.api.HttpRule(selector: str = <object object>, get: str = <object object>, put: str = <object object>, post: str = <object object>, delete: str = <object object>, patch: str = <object object>, custom: ~evmos.proto.autogen.py.google.api.CustomHttpPattern = <object object>, body: str = <object object>, response_body: str = <object object>, additional_bindings: ~typing.List[~evmos.proto.autogen.py.google.api.HttpRule] = <object object>)[source]
Bases:
MessageHttpRuledefines the mapping of an RPC method to one or more HTTP REST API methods. The mapping specifies how different portions of the RPC request message are mapped to URL path, URL query parameters, and HTTP request body. The mapping is typically specified as angoogle.api.httpannotation on the RPC method, see “google/api/annotations.proto” for details. The mapping consists of a field specifying the path template and method kind. The path template can refer to fields in the request message, as in the example below which describes a REST GET operation on a resource collection of messages: service Messaging { rpc GetMessage(GetMessageRequest) returns (Message) { option (google.api.http).get = “/v1/messages/{message_id}/{sub.subfield}”; } } message GetMessageRequest { message SubMessage { string subfield = 1; } string message_id = 1; // mapped to the URL SubMessage sub = 2; //sub.subfieldis url-mapped } message Message { string text = 1; // content of the resource } The same http annotation can alternatively be expressed inside theGRPC API ConfigurationYAML file. http: rules: - selector: <proto_package_name>.Messaging.GetMessage get: /v1/messages/{message_id}/{sub.subfield} This definition enables an automatic, bidrectional mapping of HTTP JSON to RPC. Example: HTTP | RPC —–|—–GET /v1/messages/123456/foo|GetMessage(message_id: "123456" sub: SubMessage(subfield: "foo"))In general, not only fields but also field paths can be referenced from a path pattern. Fields mapped to the path pattern cannot be repeated and must have a primitive (non-message) type. Any fields in the request message which are not bound by the path pattern automatically become (optional) HTTP query parameters. Assume the following definition of the request message: service Messaging { rpc GetMessage(GetMessageRequest) returns (Message) { option (google.api.http).get = “/v1/messages/{message_id}”; } } message GetMessageRequest { message SubMessage { string subfield = 1; } string message_id = 1; // mapped to the URL int64 revision = 2; // becomes a parameter SubMessage sub = 3; //sub.subfieldbecomes a parameter } This enables a HTTP JSON to RPC mapping as below: HTTP | RPC —–|—–GET /v1/messages/123456?revision=2&sub.subfield=foo|GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield: "foo"))Note that fields which are mapped to HTTP parameters must have a primitive type or a repeated primitive type. Message types are not allowed. In the case of a repeated type, the parameter can be repeated in the URL, as in...?param=A¶m=B. For HTTP method kinds which allow a request body, thebodyfield specifies the mapping. Consider a REST update method on the message resource collection: service Messaging { rpc UpdateMessage(UpdateMessageRequest) returns (Message) { option (google.api.http) = { put: “/v1/messages/{message_id}” body: “message” }; } } message UpdateMessageRequest { string message_id = 1; // mapped to the URL Message message = 2; // mapped to the body } The following HTTP JSON to RPC mapping is enabled, where the representation of the JSON in the request body is determined by protos JSON encoding: HTTP | RPC —–|—–PUT /v1/messages/123456 { "text": "Hi!" }|UpdateMessage(message_id: "123456" message { text: "Hi!" })The special name\*can be used in the body mapping to define that every field not bound by the path template should be mapped to the request body. This enables the following alternative definition of the update method: service Messaging { rpc UpdateMessage(Message) returns (Message) { option (google.api.http) = { put: “/v1/messages/{message_id}” body: “*” }; } } message Message { string message_id = 1; string text = 2; } The following HTTP JSON to RPC mapping is enabled: HTTP | RPC —–|—–PUT /v1/messages/123456 { "text": "Hi!" }|UpdateMessage(message_id: "123456" text: "Hi!")Note that when using\*in the body mapping, it is not possible to have HTTP parameters, as all fields not bound by the path end in the body. This makes this option more rarely used in practice of defining REST APIs. The common usage of\*is in custom methods which don’t use the URL at all for transferring data. It is possible to define multiple HTTP methods for one RPC by using theadditional_bindingsoption. Example: service Messaging { rpc GetMessage(GetMessageRequest) returns (Message) { option (google.api.http) = { get: “/v1/messages/{message_id}” additional_bindings { get: “/v1/users/{user_id}/messages/{message_id}” } }; } } message GetMessageRequest { string message_id = 1; string user_id = 2; } This enables the following two alternative HTTP JSON to RPC mappings: HTTP | RPC —–|—–GET /v1/messages/123456|GetMessage(message_id: "123456")GET /v1/users/me/messages/123456|GetMessage(user_id: "me" message_id: "123456")# Rules for HTTP mapping The rules for mapping HTTP path, query parameters, and body fields to the request message are as follows: 1. Thebodyfield specifies either\*or a field path, or is omitted. If omitted, it indicates there is no HTTP request body. 2. Leaf fields (recursive expansion of nested messages in the request) can be classified into three types: (a) Matched in the URL template. (b) Covered by body (if body is\*, everything except (a) fields; else everything under the body field) (c) All other fields. 3. URL query parameters found in the HTTP request are mapped to (c) fields. 4. Any body sent with an HTTP request can contain only (b) fields. The syntax of the path template is as follows: Template = “/” Segments [ Verb ] ; Segments = Segment { “/” Segment } ; Segment = “*” | “**” | LITERAL | Variable ; Variable = “{” FieldPath [ “=” Segments ] “}” ; FieldPath = IDENT { “.” IDENT } ; Verb = “:” LITERAL ; The syntax\*matches a single path segment. The syntax\*\*matches zero or more path segments, which must be the last part of the path except theVerb. The syntaxLITERALmatches literal text in the path. The syntaxVariablematches part of the URL path as specified by its template. A variable template must not contain other variables. If a variable matches a single path segment, its template may be omitted, e.g.{var}is equivalent to{var=\*}. If a variable contains exactly one path segment, such as"{var}"or"{var=\*}", when such a variable is expanded into a URL path, all characters except[-_.~0-9a-zA-Z]are percent-encoded. Such variables show up in the Discovery Document as{var}. If a variable contains one or more path segments, such as"{var=foo/\*}"or"{var=\*\*}", when such a variable is expanded into a URL path, all characters except[-_.~/0-9a-zA-Z]are percent-encoded. Such variables show up in the Discovery Document as{+var}. NOTE: While the single segment variable matches the semantics ofRFC 6570 <https://www.rfc-editor.org/rfc/rfc6570>``_ Section 3.2.2 Simple String Expansion, the multi segment variable \*\*does not\*\* match RFC 6570 Reserved Expansion. The reason is that the Reserved Expansion does not expand special characters like ``?and#, which would lead to invalid URLs. NOTE: the field paths in variables and in thebodymust not refer to repeated fields or map fields.- additional_bindings: List[HttpRule] = <object object>
Additional HTTP bindings for the selector. Nested bindings must not contain an
additional_bindingsfield themselves (that is, the nesting may only be one level deep).
- body: str = <object object>
The name of the request field whose value is mapped to the HTTP body, or
\*for mapping all fields not captured by the path pattern to the HTTP body. NOTE: the referred field must not be a repeated field and must be present at the top-level of request message type.
- custom: CustomHttpPattern = <object object>
The custom pattern is used for specifying an HTTP method that is not included in the
patternfield, such as HEAD, or “*” to leave the HTTP method unspecified for this rule. The wild-card rule is useful for services that provide content to Web (HTML) clients.