github.com/yoogoc/kratos-scaffold@v0.0.0-20240402032722-a538b3c18955/project_generator/resources/http.proto (about) 1 // Copyright 2015 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 // Defines the HTTP configuration for an API service. It contains a list of 27 // [HttpRule][google.api.HttpRule], each specifying the mapping of an RPC method 28 // to one or more HTTP REST API methods. 29 message Http { 30 // A list of HTTP configuration rules that apply to individual API methods. 31 // 32 // **NOTE:** All service configuration rules follow "last one wins" order. 33 repeated HttpRule rules = 1; 34 35 // When set to true, URL path parameters will be fully URI-decoded except in 36 // cases of single segment matches in reserved expansion, where "%2F" will be 37 // left encoded. 38 // 39 // The default behavior is to not decode RFC 6570 reserved characters in multi 40 // segment matches. 41 bool fully_decode_reserved_expansion = 2; 42 } 43 44 // # gRPC Transcoding 45 // 46 // gRPC Transcoding is a feature for mapping between a gRPC method and one or 47 // more HTTP REST endpoints. It allows developers to build a single API service 48 // that supports both gRPC APIs and REST APIs. Many systems, including [Google 49 // APIs](https://github.com/googleapis/googleapis), 50 // [Cloud Endpoints](https://cloud.google.com/endpoints), [gRPC 51 // Gateway](https://github.com/grpc-ecosystem/grpc-gateway), 52 // and [Envoy](https://github.com/envoyproxy/envoy) proxy support this feature 53 // and use it for large scale production services. 54 // 55 // `HttpRule` defines the schema of the gRPC/REST mapping. The mapping specifies 56 // how different portions of the gRPC request message are mapped to the URL 57 // path, URL query parameters, and HTTP request body. It also controls how the 58 // gRPC response message is mapped to the HTTP response body. `HttpRule` is 59 // typically specified as an `google.api.http` annotation on the gRPC method. 60 // 61 // Each mapping specifies a URL path template and an HTTP method. The path 62 // template may refer to one or more fields in the gRPC request message, as long 63 // as each field is a non-repeated field with a primitive (non-message) type. 64 // The path template controls how fields of the request message are mapped to 65 // the URL path. 66 // 67 // Example: 68 // 69 // service Messaging { 70 // rpc GetMessage(GetMessageRequest) returns (Message) { 71 // option (google.api.http) = { 72 // get: "/v1/{name=messages/*}" 73 // }; 74 // } 75 // } 76 // message GetMessageRequest { 77 // string name = 1; // Mapped to URL path. 78 // } 79 // message Message { 80 // string text = 1; // The resource content. 81 // } 82 // 83 // This enables an HTTP REST to gRPC mapping as below: 84 // 85 // HTTP | gRPC 86 // -----|----- 87 // `GET /v1/messages/123456` | `GetMessage(name: "messages/123456")` 88 // 89 // Any fields in the request message which are not bound by the path template 90 // automatically become HTTP query parameters if there is no HTTP request body. 91 // For example: 92 // 93 // service Messaging { 94 // rpc GetMessage(GetMessageRequest) returns (Message) { 95 // option (google.api.http) = { 96 // get:"/v1/messages/{message_id}" 97 // }; 98 // } 99 // } 100 // message GetMessageRequest { 101 // message SubMessage { 102 // string subfield = 1; 103 // } 104 // string message_id = 1; // Mapped to URL path. 105 // int64 revision = 2; // Mapped to URL query parameter `revision`. 106 // SubMessage sub = 3; // Mapped to URL query parameter `sub.subfield`. 107 // } 108 // 109 // This enables a HTTP JSON to RPC mapping as below: 110 // 111 // HTTP | gRPC 112 // -----|----- 113 // `GET /v1/messages/123456?revision=2&sub.subfield=foo` | 114 // `GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield: 115 // "foo"))` 116 // 117 // Note that fields which are mapped to URL query parameters must have a 118 // primitive type or a repeated primitive type or a non-repeated message type. 119 // In the case of a repeated type, the parameter can be repeated in the URL 120 // as `...?param=A¶m=B`. In the case of a message type, each field of the 121 // message is mapped to a separate parameter, such as 122 // `...?foo.a=A&foo.b=B&foo.c=C`. 123 // 124 // For HTTP methods that allow a request body, the `body` field 125 // specifies the mapping. Consider a REST update method on the 126 // message resource collection: 127 // 128 // service Messaging { 129 // rpc UpdateMessage(UpdateMessageRequest) returns (Message) { 130 // option (google.api.http) = { 131 // patch: "/v1/messages/{message_id}" 132 // body: "message" 133 // }; 134 // } 135 // } 136 // message UpdateMessageRequest { 137 // string message_id = 1; // mapped to the URL 138 // Message message = 2; // mapped to the body 139 // } 140 // 141 // The following HTTP JSON to RPC mapping is enabled, where the 142 // representation of the JSON in the request body is determined by 143 // protos JSON encoding: 144 // 145 // HTTP | gRPC 146 // -----|----- 147 // `PATCH /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id: 148 // "123456" message { text: "Hi!" })` 149 // 150 // The special name `*` can be used in the body mapping to define that 151 // every field not bound by the path template should be mapped to the 152 // request body. This enables the following alternative definition of 153 // the update method: 154 // 155 // service Messaging { 156 // rpc UpdateMessage(Message) returns (Message) { 157 // option (google.api.http) = { 158 // patch: "/v1/messages/{message_id}" 159 // body: "*" 160 // }; 161 // } 162 // } 163 // message Message { 164 // string message_id = 1; 165 // string text = 2; 166 // } 167 // 168 // 169 // The following HTTP JSON to RPC mapping is enabled: 170 // 171 // HTTP | gRPC 172 // -----|----- 173 // `PATCH /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id: 174 // "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 when 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 // This enables the following two alternative HTTP JSON to RPC mappings: 201 // 202 // HTTP | gRPC 203 // -----|----- 204 // `GET /v1/messages/123456` | `GetMessage(message_id: "123456")` 205 // `GET /v1/users/me/messages/123456` | `GetMessage(user_id: "me" message_id: 206 // "123456")` 207 // 208 // ## Rules for HTTP mapping 209 // 210 // 1. Leaf request fields (recursive expansion nested messages in the request 211 // message) are classified into three categories: 212 // - Fields referred by the path template. They are passed via the URL path. 213 // - Fields referred by the [HttpRule.body][google.api.HttpRule.body]. They are passed via the HTTP 214 // request body. 215 // - All other fields are passed via the URL query parameters, and the 216 // parameter name is the field path in the request message. A repeated 217 // field can be represented as multiple query parameters under the same 218 // name. 219 // 2. If [HttpRule.body][google.api.HttpRule.body] is "*", there is no URL query parameter, all fields 220 // are passed via URL path and HTTP request body. 221 // 3. If [HttpRule.body][google.api.HttpRule.body] is omitted, there is no HTTP request body, all 222 // fields are passed via URL path and URL query parameters. 223 // 224 // ### Path template syntax 225 // 226 // Template = "/" Segments [ Verb ] ; 227 // Segments = Segment { "/" Segment } ; 228 // Segment = "*" | "**" | LITERAL | Variable ; 229 // Variable = "{" FieldPath [ "=" Segments ] "}" ; 230 // FieldPath = IDENT { "." IDENT } ; 231 // Verb = ":" LITERAL ; 232 // 233 // The syntax `*` matches a single URL path segment. The syntax `**` matches 234 // zero or more URL path segments, which must be the last part of the URL path 235 // except the `Verb`. 236 // 237 // The syntax `Variable` matches part of the URL path as specified by its 238 // template. A variable template must not contain other variables. If a variable 239 // matches a single path segment, its template may be omitted, e.g. `{var}` 240 // is equivalent to `{var=*}`. 241 // 242 // The syntax `LITERAL` matches literal text in the URL path. If the `LITERAL` 243 // contains any reserved character, such characters should be percent-encoded 244 // before the matching. 245 // 246 // If a variable contains exactly one path segment, such as `"{var}"` or 247 // `"{var=*}"`, when such a variable is expanded into a URL path on the client 248 // side, all characters except `[-_.~0-9a-zA-Z]` are percent-encoded. The 249 // server side does the reverse decoding. Such variables show up in the 250 // [Discovery 251 // Document](https://developers.google.com/discovery/v1/reference/apis) as 252 // `{var}`. 253 // 254 // If a variable contains multiple path segments, such as `"{var=foo/*}"` 255 // or `"{var=**}"`, when such a variable is expanded into a URL path on the 256 // client side, all characters except `[-_.~/0-9a-zA-Z]` are percent-encoded. 257 // The server side does the reverse decoding, except "%2F" and "%2f" are left 258 // unchanged. Such variables show up in the 259 // [Discovery 260 // Document](https://developers.google.com/discovery/v1/reference/apis) as 261 // `{+var}`. 262 // 263 // ## Using gRPC API Service Configuration 264 // 265 // gRPC API Service Configuration (service config) is a configuration language 266 // for configuring a gRPC service to become a user-facing product. The 267 // service config is simply the YAML representation of the `google.api.Service` 268 // proto message. 269 // 270 // As an alternative to annotating your proto file, you can configure gRPC 271 // transcoding in your service config YAML files. You do this by specifying a 272 // `HttpRule` that maps the gRPC method to a REST endpoint, achieving the same 273 // effect as the proto annotation. This can be particularly useful if you 274 // have a proto that is reused in multiple services. Note that any transcoding 275 // specified in the service config will override any matching transcoding 276 // configuration in the proto. 277 // 278 // Example: 279 // 280 // http: 281 // rules: 282 // # Selects a gRPC method and applies HttpRule to it. 283 // - selector: example.v1.Messaging.GetMessage 284 // get: /v1/messages/{message_id}/{sub.subfield} 285 // 286 // ## Special notes 287 // 288 // When gRPC Transcoding is used to map a gRPC to JSON REST endpoints, the 289 // proto to JSON conversion must follow the [proto3 290 // specification](https://developers.google.com/protocol-buffers/docs/proto3#json). 291 // 292 // While the single segment variable follows the semantics of 293 // [RFC 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.2 Simple String 294 // Expansion, the multi segment variable **does not** follow RFC 6570 Section 295 // 3.2.3 Reserved Expansion. The reason is that the Reserved Expansion 296 // does not expand special characters like `?` and `#`, which would lead 297 // to invalid URLs. As the result, gRPC Transcoding uses a custom encoding 298 // for multi segment variables. 299 // 300 // The path variables **must not** refer to any repeated or mapped field, 301 // because client libraries are not capable of handling such variable expansion. 302 // 303 // The path variables **must not** capture the leading "/" character. The reason 304 // is that the most common use case "{var}" does not capture the leading "/" 305 // character. For consistency, all path variables must share the same behavior. 306 // 307 // Repeated message fields must not be mapped to URL query parameters, because 308 // no client library can support such complicated mapping. 309 // 310 // If an API needs to use a JSON array for request or response body, it can map 311 // the request or response body to a repeated field. However, some gRPC 312 // Transcoding implementations may not support this feature. 313 message HttpRule { 314 // Selects a method to which this rule applies. 315 // 316 // Refer to [selector][google.api.DocumentationRule.selector] for syntax details. 317 string selector = 1; 318 319 // Determines the URL pattern is matched by this rules. This pattern can be 320 // used with any of the {get|put|post|delete|patch} methods. A custom method 321 // can be defined using the 'custom' field. 322 oneof pattern { 323 // Maps to HTTP GET. Used for listing and getting information about 324 // resources. 325 string get = 2; 326 327 // Maps to HTTP PUT. Used for replacing a resource. 328 string put = 3; 329 330 // Maps to HTTP POST. Used for creating a resource or performing an action. 331 string post = 4; 332 333 // Maps to HTTP DELETE. Used for deleting a resource. 334 string delete = 5; 335 336 // Maps to HTTP PATCH. Used for updating a resource. 337 string patch = 6; 338 339 // The custom pattern is used for specifying an HTTP method that is not 340 // included in the `pattern` field, such as HEAD, or "*" to leave the 341 // HTTP method unspecified for this rule. The wild-card rule is useful 342 // for services that provide content to Web (HTML) clients. 343 CustomHttpPattern custom = 8; 344 } 345 346 // The name of the request field whose value is mapped to the HTTP request 347 // body, or `*` for mapping all request fields not captured by the path 348 // pattern to the HTTP body, or omitted for not having any HTTP request body. 349 // 350 // NOTE: the referred field must be present at the top-level of the request 351 // message type. 352 string body = 7; 353 354 // Optional. The name of the response field whose value is mapped to the HTTP 355 // response body. When omitted, the entire response message will be used 356 // as the HTTP response body. 357 // 358 // NOTE: The referred field must be present at the top-level of the response 359 // message type. 360 string response_body = 12; 361 362 // Additional HTTP bindings for the selector. Nested bindings must 363 // not contain an `additional_bindings` field themselves (that is, 364 // the nesting may only be one level deep). 365 repeated HttpRule additional_bindings = 11; 366 } 367 368 // A custom pattern is used for defining custom HTTP verb. 369 message CustomHttpPattern { 370 // The name of this custom HTTP verb. 371 string kind = 1; 372 373 // The path matched by this custom verb. 374 string path = 2; 375 }