|
| 1 | +// Copyright 2016 Google Inc. |
| 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 a 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 | + |
| 37 | +// `HttpRule` defines the mapping of an RPC method to one or more HTTP |
| 38 | +// REST APIs. The mapping determines what portions of the request |
| 39 | +// message are populated from the path, query parameters, or body of |
| 40 | +// the HTTP request. The mapping is typically specified as an |
| 41 | +// `google.api.http` annotation, see "google/api/annotations.proto" |
| 42 | +// for details. |
| 43 | +// |
| 44 | +// The mapping consists of a field specifying the path template and |
| 45 | +// method kind. The path template can refer to fields in the request |
| 46 | +// message, as in the example below which describes a REST GET |
| 47 | +// operation on a resource collection of messages: |
| 48 | +// |
| 49 | +// |
| 50 | +// service Messaging { |
| 51 | +// rpc GetMessage(GetMessageRequest) returns (Message) { |
| 52 | +// option (google.api.http).get = "/v1/messages/{message_id}/{sub.subfield}"; |
| 53 | +// } |
| 54 | +// } |
| 55 | +// message GetMessageRequest { |
| 56 | +// message SubMessage { |
| 57 | +// string subfield = 1; |
| 58 | +// } |
| 59 | +// string message_id = 1; // mapped to the URL |
| 60 | +// SubMessage sub = 2; // `sub.subfield` is url-mapped |
| 61 | +// } |
| 62 | +// message Message { |
| 63 | +// string text = 1; // content of the resource |
| 64 | +// } |
| 65 | +// |
| 66 | +// The same http annotation can alternatively be expressed inside the |
| 67 | +// `GRPC API Configuration` YAML file. |
| 68 | +// |
| 69 | +// http: |
| 70 | +// rules: |
| 71 | +// - selector: <proto_package_name>.Messaging.GetMessage |
| 72 | +// get: /v1/messages/{message_id}/{sub.subfield} |
| 73 | +// |
| 74 | +// This definition enables an automatic, bidrectional mapping of HTTP |
| 75 | +// JSON to RPC. Example: |
| 76 | +// |
| 77 | +// HTTP | RPC |
| 78 | +// -----|----- |
| 79 | +// `GET /v1/messages/123456/foo` | `GetMessage(message_id: "123456" sub: SubMessage(subfield: "foo"))` |
| 80 | +// |
| 81 | +// In general, not only fields but also field paths can be referenced |
| 82 | +// from a path pattern. Fields mapped to the path pattern cannot be |
| 83 | +// repeated and must have a primitive (non-message) type. |
| 84 | +// |
| 85 | +// Any fields in the request message which are not bound by the path |
| 86 | +// pattern automatically become (optional) HTTP query |
| 87 | +// parameters. Assume the following definition of the request message: |
| 88 | +// |
| 89 | +// |
| 90 | +// message GetMessageRequest { |
| 91 | +// message SubMessage { |
| 92 | +// string subfield = 1; |
| 93 | +// } |
| 94 | +// string message_id = 1; // mapped to the URL |
| 95 | +// int64 revision = 2; // becomes a parameter |
| 96 | +// SubMessage sub = 3; // `sub.subfield` becomes a parameter |
| 97 | +// } |
| 98 | +// |
| 99 | +// |
| 100 | +// This enables a HTTP JSON to RPC mapping as below: |
| 101 | +// |
| 102 | +// HTTP | RPC |
| 103 | +// -----|----- |
| 104 | +// `GET /v1/messages/123456?revision=2&sub.subfield=foo` | `GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield: "foo"))` |
| 105 | +// |
| 106 | +// Note that fields which are mapped to HTTP parameters must have a |
| 107 | +// primitive type or a repeated primitive type. Message types are not |
| 108 | +// allowed. In the case of a repeated type, the parameter can be |
| 109 | +// repeated in the URL, as in `...?param=A¶m=B`. |
| 110 | +// |
| 111 | +// For HTTP method kinds which allow a request body, the `body` field |
| 112 | +// specifies the mapping. Consider a REST update method on the |
| 113 | +// message resource collection: |
| 114 | +// |
| 115 | +// |
| 116 | +// service Messaging { |
| 117 | +// rpc UpdateMessage(UpdateMessageRequest) returns (Message) { |
| 118 | +// option (google.api.http) = { |
| 119 | +// put: "/v1/messages/{message_id}" |
| 120 | +// body: "message" |
| 121 | +// }; |
| 122 | +// } |
| 123 | +// } |
| 124 | +// message UpdateMessageRequest { |
| 125 | +// string message_id = 1; // mapped to the URL |
| 126 | +// Message message = 2; // mapped to the body |
| 127 | +// } |
| 128 | +// |
| 129 | +// |
| 130 | +// The following HTTP JSON to RPC mapping is enabled, where the |
| 131 | +// representation of the JSON in the request body is determined by |
| 132 | +// protos JSON encoding: |
| 133 | +// |
| 134 | +// HTTP | RPC |
| 135 | +// -----|----- |
| 136 | +// `PUT /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id: "123456" message { text: "Hi!" })` |
| 137 | +// |
| 138 | +// The special name `*` can be used in the body mapping to define that |
| 139 | +// every field not bound by the path template should be mapped to the |
| 140 | +// request body. This enables the following alternative definition of |
| 141 | +// the update method: |
| 142 | +// |
| 143 | +// service Messaging { |
| 144 | +// rpc UpdateMessage(Message) returns (Message) { |
| 145 | +// option (google.api.http) = { |
| 146 | +// put: "/v1/messages/{message_id}" |
| 147 | +// body: "*" |
| 148 | +// }; |
| 149 | +// } |
| 150 | +// } |
| 151 | +// message Message { |
| 152 | +// string message_id = 1; |
| 153 | +// string text = 2; |
| 154 | +// } |
| 155 | +// |
| 156 | +// |
| 157 | +// The following HTTP JSON to RPC mapping is enabled: |
| 158 | +// |
| 159 | +// HTTP | RPC |
| 160 | +// -----|----- |
| 161 | +// `PUT /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id: "123456" text: "Hi!")` |
| 162 | +// |
| 163 | +// Note that when using `*` in the body mapping, it is not possible to |
| 164 | +// have HTTP parameters, as all fields not bound by the path end in |
| 165 | +// the body. This makes this option more rarely used in practice of |
| 166 | +// defining REST APIs. The common usage of `*` is in custom methods |
| 167 | +// which don't use the URL at all for transferring data. |
| 168 | +// |
| 169 | +// It is possible to define multiple HTTP methods for one RPC by using |
| 170 | +// the `additional_bindings` option. Example: |
| 171 | +// |
| 172 | +// service Messaging { |
| 173 | +// rpc GetMessage(GetMessageRequest) returns (Message) { |
| 174 | +// option (google.api.http) = { |
| 175 | +// get: "/v1/messages/{message_id}" |
| 176 | +// additional_bindings { |
| 177 | +// get: "/v1/users/{user_id}/messages/{message_id}" |
| 178 | +// } |
| 179 | +// }; |
| 180 | +// } |
| 181 | +// } |
| 182 | +// message GetMessageRequest { |
| 183 | +// string message_id = 1; |
| 184 | +// string user_id = 2; |
| 185 | +// } |
| 186 | +// |
| 187 | +// |
| 188 | +// This enables the following two alternative HTTP JSON to RPC |
| 189 | +// mappings: |
| 190 | +// |
| 191 | +// HTTP | RPC |
| 192 | +// -----|----- |
| 193 | +// `GET /v1/messages/123456` | `GetMessage(message_id: "123456")` |
| 194 | +// `GET /v1/users/me/messages/123456` | `GetMessage(user_id: "me" message_id: "123456")` |
| 195 | +// |
| 196 | +// # Rules for HTTP mapping |
| 197 | +// |
| 198 | +// The rules for mapping HTTP path, query parameters, and body fields |
| 199 | +// to the request message are as follows: |
| 200 | +// |
| 201 | +// 1. The `body` field specifies either `*` or a field path, or is |
| 202 | +// omitted. If omitted, it assumes there is no HTTP body. |
| 203 | +// 2. Leaf fields (recursive expansion of nested messages in the |
| 204 | +// request) can be classified into three types: |
| 205 | +// (a) Matched in the URL template. |
| 206 | +// (b) Covered by body (if body is `*`, everything except (a) fields; |
| 207 | +// else everything under the body field) |
| 208 | +// (c) All other fields. |
| 209 | +// 3. URL query parameters found in the HTTP request are mapped to (c) fields. |
| 210 | +// 4. Any body sent with an HTTP request can contain only (b) fields. |
| 211 | +// |
| 212 | +// The syntax of the path template is as follows: |
| 213 | +// |
| 214 | +// Template = "/" Segments [ Verb ] ; |
| 215 | +// Segments = Segment { "/" Segment } ; |
| 216 | +// Segment = "*" | "**" | LITERAL | Variable ; |
| 217 | +// Variable = "{" FieldPath [ "=" Segments ] "}" ; |
| 218 | +// FieldPath = IDENT { "." IDENT } ; |
| 219 | +// Verb = ":" LITERAL ; |
| 220 | +// |
| 221 | +// The syntax `*` matches a single path segment. It follows the semantics of |
| 222 | +// [RFC 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.2 Simple String |
| 223 | +// Expansion. |
| 224 | +// |
| 225 | +// The syntax `**` matches zero or more path segments. It follows the semantics |
| 226 | +// of [RFC 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.3 Reserved |
| 227 | +// Expansion. NOTE: it must be the last segment in the path except the Verb. |
| 228 | +// |
| 229 | +// The syntax `LITERAL` matches literal text in the URL path. |
| 230 | +// |
| 231 | +// The syntax `Variable` matches the entire path as specified by its template; |
| 232 | +// this nested template must not contain further variables. If a variable |
| 233 | +// matches a single path segment, its template may be omitted, e.g. `{var}` |
| 234 | +// is equivalent to `{var=*}`. |
| 235 | +// |
| 236 | +// NOTE: the field paths in variables and in the `body` must not refer to |
| 237 | +// repeated fields or map fields. |
| 238 | +// |
| 239 | +// Use CustomHttpPattern to specify any HTTP method that is not included in the |
| 240 | +// `pattern` field, such as HEAD, or "*" to leave the HTTP method unspecified for |
| 241 | +// a given URL path rule. The wild-card rule is useful for services that provide |
| 242 | +// content to Web (HTML) clients. |
| 243 | +message HttpRule { |
| 244 | + // Selects methods to which this rule applies. |
| 245 | + // |
| 246 | + // Refer to [selector][google.api.DocumentationRule.selector] for syntax details. |
| 247 | + string selector = 1; |
| 248 | + |
| 249 | + // Determines the URL pattern is matched by this rules. This pattern can be |
| 250 | + // used with any of the {get|put|post|delete|patch} methods. A custom method |
| 251 | + // can be defined using the 'custom' field. |
| 252 | + oneof pattern { |
| 253 | + // Used for listing and getting information about resources. |
| 254 | + string get = 2; |
| 255 | + |
| 256 | + // Used for updating a resource. |
| 257 | + string put = 3; |
| 258 | + |
| 259 | + // Used for creating a resource. |
| 260 | + string post = 4; |
| 261 | + |
| 262 | + // Used for deleting a resource. |
| 263 | + string delete = 5; |
| 264 | + |
| 265 | + // Used for updating a resource. |
| 266 | + string patch = 6; |
| 267 | + |
| 268 | + // Custom pattern is used for defining custom verbs. |
| 269 | + CustomHttpPattern custom = 8; |
| 270 | + } |
| 271 | + |
| 272 | + // The name of the request field whose value is mapped to the HTTP body, or |
| 273 | + // `*` for mapping all fields not captured by the path pattern to the HTTP |
| 274 | + // body. NOTE: the referred field must not be a repeated field and must be |
| 275 | + // present at the top-level of request message type. |
| 276 | + string body = 7; |
| 277 | + |
| 278 | + // Additional HTTP bindings for the selector. Nested bindings must |
| 279 | + // not contain an `additional_bindings` field themselves (that is, |
| 280 | + // the nesting may only be one level deep). |
| 281 | + repeated HttpRule additional_bindings = 11; |
| 282 | +} |
| 283 | + |
| 284 | +// A custom pattern is used for defining custom HTTP verb. |
| 285 | +message CustomHttpPattern { |
| 286 | + // The name of this custom HTTP verb. |
| 287 | + string kind = 1; |
| 288 | + |
| 289 | + // The path matched by this custom verb. |
| 290 | + string path = 2; |
| 291 | +} |
0 commit comments