1// Copyright 2023 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 15syntax = "proto3"; 16 17package google.api; 18 19option cc_enable_arenas = true; 20option go_package = "google.golang.org/genproto/googleapis/api/annotations;annotations"; 21option java_multiple_files = true; 22option java_outer_classname = "HttpProto"; 23option java_package = "com.google.api"; 24option 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. 29message 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 214// are passed via the HTTP 215// request body. 216// - All other fields are passed via the URL query parameters, and the 217// parameter name is the field path in the request message. A repeated 218// field can be represented as multiple query parameters under the same 219// name. 220// 2. If [HttpRule.body][google.api.HttpRule.body] is "*", there is no URL 221// query parameter, all fields 222// are passed via URL path and HTTP request body. 223// 3. If [HttpRule.body][google.api.HttpRule.body] is omitted, there is no HTTP 224// request body, all 225// fields are passed via URL path and URL query parameters. 226// 227// ### Path template syntax 228// 229// Template = "/" Segments [ Verb ] ; 230// Segments = Segment { "/" Segment } ; 231// Segment = "*" | "**" | LITERAL | Variable ; 232// Variable = "{" FieldPath [ "=" Segments ] "}" ; 233// FieldPath = IDENT { "." IDENT } ; 234// Verb = ":" LITERAL ; 235// 236// The syntax `*` matches a single URL path segment. The syntax `**` matches 237// zero or more URL path segments, which must be the last part of the URL path 238// except the `Verb`. 239// 240// The syntax `Variable` matches part of the URL path as specified by its 241// template. A variable template must not contain other variables. If a variable 242// matches a single path segment, its template may be omitted, e.g. `{var}` 243// is equivalent to `{var=*}`. 244// 245// The syntax `LITERAL` matches literal text in the URL path. If the `LITERAL` 246// contains any reserved character, such characters should be percent-encoded 247// before the matching. 248// 249// If a variable contains exactly one path segment, such as `"{var}"` or 250// `"{var=*}"`, when such a variable is expanded into a URL path on the client 251// side, all characters except `[-_.~0-9a-zA-Z]` are percent-encoded. The 252// server side does the reverse decoding. Such variables show up in the 253// [Discovery 254// Document](https://developers.google.com/discovery/v1/reference/apis) as 255// `{var}`. 256// 257// If a variable contains multiple path segments, such as `"{var=foo/*}"` 258// or `"{var=**}"`, when such a variable is expanded into a URL path on the 259// client side, all characters except `[-_.~/0-9a-zA-Z]` are percent-encoded. 260// The server side does the reverse decoding, except "%2F" and "%2f" are left 261// unchanged. Such variables show up in the 262// [Discovery 263// Document](https://developers.google.com/discovery/v1/reference/apis) as 264// `{+var}`. 265// 266// ## Using gRPC API Service Configuration 267// 268// gRPC API Service Configuration (service config) is a configuration language 269// for configuring a gRPC service to become a user-facing product. The 270// service config is simply the YAML representation of the `google.api.Service` 271// proto message. 272// 273// As an alternative to annotating your proto file, you can configure gRPC 274// transcoding in your service config YAML files. You do this by specifying a 275// `HttpRule` that maps the gRPC method to a REST endpoint, achieving the same 276// effect as the proto annotation. This can be particularly useful if you 277// have a proto that is reused in multiple services. Note that any transcoding 278// specified in the service config will override any matching transcoding 279// configuration in the proto. 280// 281// Example: 282// 283// http: 284// rules: 285// # Selects a gRPC method and applies HttpRule to it. 286// - selector: example.v1.Messaging.GetMessage 287// get: /v1/messages/{message_id}/{sub.subfield} 288// 289// ## Special notes 290// 291// When gRPC Transcoding is used to map a gRPC to JSON REST endpoints, the 292// proto to JSON conversion must follow the [proto3 293// specification](https://developers.google.com/protocol-buffers/docs/proto3#json). 294// 295// While the single segment variable follows the semantics of 296// [RFC 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.2 Simple String 297// Expansion, the multi segment variable **does not** follow RFC 6570 Section 298// 3.2.3 Reserved Expansion. The reason is that the Reserved Expansion 299// does not expand special characters like `?` and `#`, which would lead 300// to invalid URLs. As the result, gRPC Transcoding uses a custom encoding 301// for multi segment variables. 302// 303// The path variables **must not** refer to any repeated or mapped field, 304// because client libraries are not capable of handling such variable expansion. 305// 306// The path variables **must not** capture the leading "/" character. The reason 307// is that the most common use case "{var}" does not capture the leading "/" 308// character. For consistency, all path variables must share the same behavior. 309// 310// Repeated message fields must not be mapped to URL query parameters, because 311// no client library can support such complicated mapping. 312// 313// If an API needs to use a JSON array for request or response body, it can map 314// the request or response body to a repeated field. However, some gRPC 315// Transcoding implementations may not support this feature. 316message HttpRule { 317 // Selects a method to which this rule applies. 318 // 319 // Refer to [selector][google.api.DocumentationRule.selector] for syntax 320 // details. 321 string selector = 1; 322 323 // Determines the URL pattern is matched by this rules. This pattern can be 324 // used with any of the {get|put|post|delete|patch} methods. A custom method 325 // can be defined using the 'custom' field. 326 oneof pattern { 327 // Maps to HTTP GET. Used for listing and getting information about 328 // resources. 329 string get = 2; 330 331 // Maps to HTTP PUT. Used for replacing a resource. 332 string put = 3; 333 334 // Maps to HTTP POST. Used for creating a resource or performing an action. 335 string post = 4; 336 337 // Maps to HTTP DELETE. Used for deleting a resource. 338 string delete = 5; 339 340 // Maps to HTTP PATCH. Used for updating a resource. 341 string patch = 6; 342 343 // The custom pattern is used for specifying an HTTP method that is not 344 // included in the `pattern` field, such as HEAD, or "*" to leave the 345 // HTTP method unspecified for this rule. The wild-card rule is useful 346 // for services that provide content to Web (HTML) clients. 347 CustomHttpPattern custom = 8; 348 } 349 350 // The name of the request field whose value is mapped to the HTTP request 351 // body, or `*` for mapping all request fields not captured by the path 352 // pattern to the HTTP body, or omitted for not having any HTTP request body. 353 // 354 // NOTE: the referred field must be present at the top-level of the request 355 // message type. 356 string body = 7; 357 358 // Optional. The name of the response field whose value is mapped to the HTTP 359 // response body. When omitted, the entire response message will be used 360 // as the HTTP response body. 361 // 362 // NOTE: The referred field must be present at the top-level of the response 363 // message type. 364 string response_body = 12; 365 366 // Additional HTTP bindings for the selector. Nested bindings must 367 // not contain an `additional_bindings` field themselves (that is, 368 // the nesting may only be one level deep). 369 repeated HttpRule additional_bindings = 11; 370} 371 372// A custom pattern is used for defining custom HTTP verb. 373message CustomHttpPattern { 374 // The name of this custom HTTP verb. 375 string kind = 1; 376 377 // The path matched by this custom verb. 378 string path = 2; 379} 380