github.com/s7techlab/cckit@v0.10.5/third_party/google/api/http.proto (about)

     1  // Copyright 2018 Google LLC
     2  //
     3  // Licensed under the Apache License, Version 2.0 (the "License");
     4  // you may not use this file except in compliance with the License.
     5  // You may obtain a copy of the License at
     6  //
     7  //     http://www.apache.org/licenses/LICENSE-2.0
     8  //
     9  // Unless required by applicable law or agreed to in writing, software
    10  // distributed under the License is distributed on an "AS IS" BASIS,
    11  // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    12  // See the License for the specific language governing permissions and
    13  // limitations under the License.
    14  
    15  syntax = "proto3";
    16  
    17  package google.api;
    18  
    19  option cc_enable_arenas = true;
    20  option go_package = "google.golang.org/genproto/googleapis/api/annotations;annotations";
    21  option java_multiple_files = true;
    22  option java_outer_classname = "HttpProto";
    23  option java_package = "com.google.api";
    24  option objc_class_prefix = "GAPI";
    25  
    26  
    27  // Defines the HTTP configuration for an API service. It contains a list of
    28  // [HttpRule][google.api.HttpRule], each specifying the mapping of an RPC method
    29  // to one or more HTTP REST API methods.
    30  message Http {
    31      // A list of HTTP configuration rules that apply to individual API methods.
    32      //
    33      // **NOTE:** All service configuration rules follow "last one wins" order.
    34      repeated HttpRule rules = 1;
    35  
    36      // When set to true, URL path parmeters will be fully URI-decoded except in
    37      // cases of single segment matches in reserved expansion, where "%2F" will be
    38      // left encoded.
    39      //
    40      // The default behavior is to not decode RFC 6570 reserved characters in multi
    41      // segment matches.
    42      bool fully_decode_reserved_expansion = 2;
    43  }
    44  
    45  // `HttpRule` defines the mapping of an RPC method to one or more HTTP
    46  // REST API methods. The mapping specifies how different portions of the RPC
    47  // request message are mapped to URL path, URL query parameters, and
    48  // HTTP request body. The mapping is typically specified as an
    49  // `google.api.http` annotation on the RPC method,
    50  // see "google/api/annotations.proto" for details.
    51  //
    52  // The mapping consists of a field specifying the path template and
    53  // method kind.  The path template can refer to fields in the request
    54  // message, as in the example below which describes a REST GET
    55  // operation on a resource collection of messages:
    56  //
    57  //
    58  //     service Messaging {
    59  //       rpc GetMessage(GetMessageRequest) returns (Message) {
    60  //         option (google.api.http).get = "/v1/messages/{message_id}/{sub.subfield}";
    61  //       }
    62  //     }
    63  //     message GetMessageRequest {
    64  //       message SubMessage {
    65  //         string subfield = 1;
    66  //       }
    67  //       string message_id = 1; // mapped to the URL
    68  //       SubMessage sub = 2;    // `sub.subfield` is url-mapped
    69  //     }
    70  //     message Message {
    71  //       string text = 1; // content of the resource
    72  //     }
    73  //
    74  // The same http annotation can alternatively be expressed inside the
    75  // `GRPC API Configuration` YAML file.
    76  //
    77  //     http:
    78  //       rules:
    79  //         - selector: <proto_package_name>.Messaging.GetMessage
    80  //           get: /v1/messages/{message_id}/{sub.subfield}
    81  //
    82  // This definition enables an automatic, bidrectional mapping of HTTP
    83  // JSON to RPC. Example:
    84  //
    85  // HTTP | RPC
    86  // -----|-----
    87  // `GET /v1/messages/123456/foo`  | `GetMessage(message_id: "123456" sub: SubMessage(subfield: "foo"))`
    88  //
    89  // In general, not only fields but also field paths can be referenced
    90  // from a path pattern. Fields mapped to the path pattern cannot be
    91  // repeated and must have a primitive (non-message) type.
    92  //
    93  // Any fields in the request message which are not bound by the path
    94  // pattern automatically become (optional) HTTP query
    95  // parameters. Assume the following definition of the request message:
    96  //
    97  //
    98  //     service Messaging {
    99  //       rpc GetMessage(GetMessageRequest) returns (Message) {
   100  //         option (google.api.http).get = "/v1/messages/{message_id}";
   101  //       }
   102  //     }
   103  //     message GetMessageRequest {
   104  //       message SubMessage {
   105  //         string subfield = 1;
   106  //       }
   107  //       string message_id = 1; // mapped to the URL
   108  //       int64 revision = 2;    // becomes a parameter
   109  //       SubMessage sub = 3;    // `sub.subfield` becomes a parameter
   110  //     }
   111  //
   112  //
   113  // This enables a HTTP JSON to RPC mapping as below:
   114  //
   115  // HTTP | RPC
   116  // -----|-----
   117  // `GET /v1/messages/123456?revision=2&sub.subfield=foo` | `GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield: "foo"))`
   118  //
   119  // Note that fields which are mapped to HTTP parameters must have a
   120  // primitive type or a repeated primitive type. Message types are not
   121  // allowed. In the case of a repeated type, the parameter can be
   122  // repeated in the URL, as in `...?param=A&param=B`.
   123  //
   124  // For HTTP method kinds which allow a request body, the `body` field
   125  // specifies the mapping. Consider a REST update method on the
   126  // message resource collection:
   127  //
   128  //
   129  //     service Messaging {
   130  //       rpc UpdateMessage(UpdateMessageRequest) returns (Message) {
   131  //         option (google.api.http) = {
   132  //           put: "/v1/messages/{message_id}"
   133  //           body: "message"
   134  //         };
   135  //       }
   136  //     }
   137  //     message UpdateMessageRequest {
   138  //       string message_id = 1; // mapped to the URL
   139  //       Message message = 2;   // mapped to the body
   140  //     }
   141  //
   142  //
   143  // The following HTTP JSON to RPC mapping is enabled, where the
   144  // representation of the JSON in the request body is determined by
   145  // protos JSON encoding:
   146  //
   147  // HTTP | RPC
   148  // -----|-----
   149  // `PUT /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id: "123456" message { text: "Hi!" })`
   150  //
   151  // The special name `*` can be used in the body mapping to define that
   152  // every field not bound by the path template should be mapped to the
   153  // request body.  This enables the following alternative definition of
   154  // the update method:
   155  //
   156  //     service Messaging {
   157  //       rpc UpdateMessage(Message) returns (Message) {
   158  //         option (google.api.http) = {
   159  //           put: "/v1/messages/{message_id}"
   160  //           body: "*"
   161  //         };
   162  //       }
   163  //     }
   164  //     message Message {
   165  //       string message_id = 1;
   166  //       string text = 2;
   167  //     }
   168  //
   169  //
   170  // The following HTTP JSON to RPC mapping is enabled:
   171  //
   172  // HTTP | RPC
   173  // -----|-----
   174  // `PUT /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id: "123456" text: "Hi!")`
   175  //
   176  // Note that when using `*` in the body mapping, it is not possible to
   177  // have HTTP parameters, as all fields not bound by the path end in
   178  // the body. This makes this option more rarely used in practice of
   179  // defining REST APIs. The common usage of `*` is in custom methods
   180  // which don't use the URL at all for transferring data.
   181  //
   182  // It is possible to define multiple HTTP methods for one RPC by using
   183  // the `additional_bindings` option. Example:
   184  //
   185  //     service Messaging {
   186  //       rpc GetMessage(GetMessageRequest) returns (Message) {
   187  //         option (google.api.http) = {
   188  //           get: "/v1/messages/{message_id}"
   189  //           additional_bindings {
   190  //             get: "/v1/users/{user_id}/messages/{message_id}"
   191  //           }
   192  //         };
   193  //       }
   194  //     }
   195  //     message GetMessageRequest {
   196  //       string message_id = 1;
   197  //       string user_id = 2;
   198  //     }
   199  //
   200  //
   201  // This enables the following two alternative HTTP JSON to RPC
   202  // mappings:
   203  //
   204  // HTTP | RPC
   205  // -----|-----
   206  // `GET /v1/messages/123456` | `GetMessage(message_id: "123456")`
   207  // `GET /v1/users/me/messages/123456` | `GetMessage(user_id: "me" message_id: "123456")`
   208  //
   209  // # Rules for HTTP mapping
   210  //
   211  // The rules for mapping HTTP path, query parameters, and body fields
   212  // to the request message are as follows:
   213  //
   214  // 1. The `body` field specifies either `*` or a field path, or is
   215  //    omitted. If omitted, it indicates there is no HTTP request body.
   216  // 2. Leaf fields (recursive expansion of nested messages in the
   217  //    request) can be classified into three types:
   218  //     (a) Matched in the URL template.
   219  //     (b) Covered by body (if body is `*`, everything except (a) fields;
   220  //         else everything under the body field)
   221  //     (c) All other fields.
   222  // 3. URL query parameters found in the HTTP request are mapped to (c) fields.
   223  // 4. Any body sent with an HTTP request can contain only (b) fields.
   224  //
   225  // The syntax of the path template is as follows:
   226  //
   227  //     Template = "/" Segments [ Verb ] ;
   228  //     Segments = Segment { "/" Segment } ;
   229  //     Segment  = "*" | "**" | LITERAL | Variable ;
   230  //     Variable = "{" FieldPath [ "=" Segments ] "}" ;
   231  //     FieldPath = IDENT { "." IDENT } ;
   232  //     Verb     = ":" LITERAL ;
   233  //
   234  // The syntax `*` matches a single path segment. The syntax `**` matches zero
   235  // or more path segments, which must be the last part of the path except the
   236  // `Verb`. The syntax `LITERAL` matches literal text in the path.
   237  //
   238  // The syntax `Variable` matches part of the URL path as specified by its
   239  // template. A variable template must not contain other variables. If a variable
   240  // matches a single path segment, its template may be omitted, e.g. `{var}`
   241  // is equivalent to `{var=*}`.
   242  //
   243  // If a variable contains exactly one path segment, such as `"{var}"` or
   244  // `"{var=*}"`, when such a variable is expanded into a URL path, all characters
   245  // except `[-_.~0-9a-zA-Z]` are percent-encoded. Such variables show up in the
   246  // Discovery Document as `{var}`.
   247  //
   248  // If a variable contains one or more path segments, such as `"{var=foo/*}"`
   249  // or `"{var=**}"`, when such a variable is expanded into a URL path, all
   250  // characters except `[-_.~/0-9a-zA-Z]` are percent-encoded. Such variables
   251  // show up in the Discovery Document as `{+var}`.
   252  //
   253  // NOTE: While the single segment variable matches the semantics of
   254  // [RFC 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.2
   255  // Simple String Expansion, the multi segment variable **does not** match
   256  // RFC 6570 Reserved Expansion. The reason is that the Reserved Expansion
   257  // does not expand special characters like `?` and `#`, which would lead
   258  // to invalid URLs.
   259  //
   260  // NOTE: the field paths in variables and in the `body` must not refer to
   261  // repeated fields or map fields.
   262  message HttpRule {
   263      // Selects methods to which this rule applies.
   264      //
   265      // Refer to [selector][google.api.DocumentationRule.selector] for syntax details.
   266      string selector = 1;
   267  
   268      // Determines the URL pattern is matched by this rules. This pattern can be
   269      // used with any of the {get|put|post|delete|patch} methods. A custom method
   270      // can be defined using the 'custom' field.
   271      oneof pattern {
   272          // Used for listing and getting information about resources.
   273          string get = 2;
   274  
   275          // Used for updating a resource.
   276          string put = 3;
   277  
   278          // Used for creating a resource.
   279          string post = 4;
   280  
   281          // Used for deleting a resource.
   282          string delete = 5;
   283  
   284          // Used for updating a resource.
   285          string patch = 6;
   286  
   287          // The custom pattern is used for specifying an HTTP method that is not
   288          // included in the `pattern` field, such as HEAD, or "*" to leave the
   289          // HTTP method unspecified for this rule. The wild-card rule is useful
   290          // for services that provide content to Web (HTML) clients.
   291          CustomHttpPattern custom = 8;
   292      }
   293  
   294      // The name of the request field whose value is mapped to the HTTP body, or
   295      // `*` for mapping all fields not captured by the path pattern to the HTTP
   296      // body. NOTE: the referred field must not be a repeated field and must be
   297      // present at the top-level of request message type.
   298      string body = 7;
   299  
   300      // Optional. The name of the response field whose value is mapped to the HTTP
   301      // body of response. Other response fields are ignored. When
   302      // not set, the response message will be used as HTTP body of response.
   303      string response_body = 12;
   304  
   305      // Additional HTTP bindings for the selector. Nested bindings must
   306      // not contain an `additional_bindings` field themselves (that is,
   307      // the nesting may only be one level deep).
   308      repeated HttpRule additional_bindings = 11;
   309  }
   310  
   311  // A custom pattern is used for defining custom HTTP verb.
   312  message CustomHttpPattern {
   313      // The name of this custom HTTP verb.
   314      string kind = 1;
   315  
   316      // The path matched by this custom verb.
   317      string path = 2;
   318  }