1
- // Copyright 2016 Google Inc.
1
+ // Copyright 2018 Google LLC
2
2
//
3
3
// Licensed under the Apache License, Version 2.0 (the "License");
4
4
// you may not use this file except in compliance with the License.
@@ -24,22 +24,30 @@ option java_package = "com.google.api";
24
24
option objc_class_prefix = "GAPI" ;
25
25
26
26
27
- // Defines the HTTP configuration for a service. It contains a list of
27
+ // Defines the HTTP configuration for an API service. It contains a list of
28
28
// [HttpRule][google.api.HttpRule], each specifying the mapping of an RPC method
29
29
// to one or more HTTP REST API methods.
30
30
message Http {
31
31
// A list of HTTP configuration rules that apply to individual API methods.
32
32
//
33
33
// **NOTE:** All service configuration rules follow "last one wins" order.
34
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 ;
35
43
}
36
44
37
45
// `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.
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.
43
51
//
44
52
// The mapping consists of a field specifying the path template and
45
53
// method kind. The path template can refer to fields in the request
@@ -87,6 +95,11 @@ message Http {
87
95
// parameters. Assume the following definition of the request message:
88
96
//
89
97
//
98
+ // service Messaging {
99
+ // rpc GetMessage(GetMessageRequest) returns (Message) {
100
+ // option (google.api.http).get = "/v1/messages/{message_id}";
101
+ // }
102
+ // }
90
103
// message GetMessageRequest {
91
104
// message SubMessage {
92
105
// string subfield = 1;
@@ -199,7 +212,7 @@ message Http {
199
212
// to the request message are as follows:
200
213
//
201
214
// 1. The `body` field specifies either `*` or a field path, or is
202
- // omitted. If omitted, it assumes there is no HTTP body.
215
+ // omitted. If omitted, it indicates there is no HTTP request body.
203
216
// 2. Leaf fields (recursive expansion of nested messages in the
204
217
// request) can be classified into three types:
205
218
// (a) Matched in the URL template.
@@ -218,28 +231,34 @@ message Http {
218
231
// FieldPath = IDENT { "." IDENT } ;
219
232
// Verb = ":" LITERAL ;
220
233
//
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 .
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 .
224
237
//
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
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
233
240
// matches a single path segment, its template may be omitted, e.g. `{var}`
234
241
// is equivalent to `{var=*}`.
235
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
+ //
236
260
// NOTE: the field paths in variables and in the `body` must not refer to
237
261
// 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
262
message HttpRule {
244
263
// Selects methods to which this rule applies.
245
264
//
@@ -265,7 +284,10 @@ message HttpRule {
265
284
// Used for updating a resource.
266
285
string patch = 6 ;
267
286
268
- // Custom pattern is used for defining custom verbs.
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.
269
291
CustomHttpPattern custom = 8 ;
270
292
}
271
293
0 commit comments