Protocol Documentation

Table of Contents

PlaybackConfig

Information about name space and file associated with playback or recording.

Playback will play signals on namespace. Recordings will record all signals

on name space.

PlaybackInfo

Information about a playback or a recording.

PlaybackInfos

Information about all playbacks and recordings.

PlaybackMode

Status of playback.

Mode

Modes of playback and recording.

TrafficService

Handle playback and recordings.

Methods with HTTP bindings

CustomHttpPattern

A custom pattern is used for defining custom HTTP verb.

Http

Defines the HTTP configuration for an API service. It contains a list of

[HttpRule][google.api.HttpRule], each specifying the mapping of an RPC method

to one or more HTTP REST API methods.

HttpRule

# gRPC Transcoding

gRPC Transcoding is a feature for mapping between a gRPC method and one or

more HTTP REST endpoints. It allows developers to build a single API service

that supports both gRPC APIs and REST APIs. Many systems, including [Google

APIs](https://github.com/googleapis/googleapis),

[Cloud Endpoints](https://cloud.google.com/endpoints), [gRPC

Gateway](https://github.com/grpc-ecosystem/grpc-gateway),

and [Envoy](https://github.com/envoyproxy/envoy) proxy support this feature

and use it for large scale production services.

`HttpRule` defines the schema of the gRPC/REST mapping. The mapping specifies

how different portions of the gRPC request message are mapped to the URL

path, URL query parameters, and HTTP request body. It also controls how the

gRPC response message is mapped to the HTTP response body. `HttpRule` is

typically specified as an `google.api.http` annotation on the gRPC method.

Each mapping specifies a URL path template and an HTTP method. The path

template may refer to one or more fields in the gRPC request message, as long

as each field is a non-repeated field with a primitive (non-message) type.

The path template controls how fields of the request message are mapped to

the URL path.

Example:

service Messaging {

rpc GetMessage(GetMessageRequest) returns (Message) {

option (google.api.http) = {

get: "/v1/{name=messages/*}"

};

}

}

message GetMessageRequest {

string name = 1; // Mapped to URL path.

}

message Message {

string text = 1; // The resource content.

}

This enables an HTTP REST to gRPC mapping as below:

HTTP | gRPC

-----|-----

`GET /v1/messages/123456` | `GetMessage(name: "messages/123456")`

Any fields in the request message which are not bound by the path template

automatically become HTTP query parameters if there is no HTTP request body.

For example:

service Messaging {

rpc GetMessage(GetMessageRequest) returns (Message) {

option (google.api.http) = {

get:"/v1/messages/{message_id}"

};

}

}

message GetMessageRequest {

message SubMessage {

string subfield = 1;

}

string message_id = 1; // Mapped to URL path.

int64 revision = 2; // Mapped to URL query parameter `revision`.

SubMessage sub = 3; // Mapped to URL query parameter `sub.subfield`.

}

This enables a HTTP JSON to RPC mapping as below:

HTTP | gRPC

-----|-----

`GET /v1/messages/123456?revision=2&sub.subfield=foo` |

`GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield:

"foo"))`

Note that fields which are mapped to URL query parameters must have a

primitive type or a repeated primitive type or a non-repeated message type.

In the case of a repeated type, the parameter can be repeated in the URL

as `...?param=A¶m=B`. In the case of a message type, each field of the

message is mapped to a separate parameter, such as

`...?foo.a=A&foo.b=B&foo.c=C`.

For HTTP methods that allow a request body, the `body` field

specifies the mapping. Consider a REST update method on the

message resource collection:

service Messaging {

rpc UpdateMessage(UpdateMessageRequest) returns (Message) {

option (google.api.http) = {

patch: "/v1/messages/{message_id}"

body: "message"

};

}

}

message UpdateMessageRequest {

string message_id = 1; // mapped to the URL

Message message = 2; // mapped to the body

}

The following HTTP JSON to RPC mapping is enabled, where the

representation of the JSON in the request body is determined by

protos JSON encoding:

HTTP | gRPC

-----|-----

`PATCH /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id:

"123456" message { text: "Hi!" })`

The special name `*` can be used in the body mapping to define that

every field not bound by the path template should be mapped to the

request body. This enables the following alternative definition of

the update method:

service Messaging {

rpc UpdateMessage(Message) returns (Message) {

option (google.api.http) = {

patch: "/v1/messages/{message_id}"

body: "*"

};

}

}

message Message {

string message_id = 1;

string text = 2;

}

The following HTTP JSON to RPC mapping is enabled:

HTTP | gRPC

-----|-----

`PATCH /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id:

"123456" text: "Hi!")`

Note that when using `*` in the body mapping, it is not possible to

have HTTP parameters, as all fields not bound by the path end in

the body. This makes this option more rarely used in practice when

defining REST APIs. The common usage of `*` is in custom methods

which don't use the URL at all for transferring data.

It is possible to define multiple HTTP methods for one RPC by using

the `additional_bindings` option. Example:

service Messaging {

rpc GetMessage(GetMessageRequest) returns (Message) {

option (google.api.http) = {

get: "/v1/messages/{message_id}"

additional_bindings {

get: "/v1/users/{user_id}/messages/{message_id}"

}

};

}

}

message GetMessageRequest {

string message_id = 1;

string user_id = 2;

}

This enables the following two alternative HTTP JSON to RPC mappings:

HTTP | gRPC

-----|-----

`GET /v1/messages/123456` | `GetMessage(message_id: "123456")`

`GET /v1/users/me/messages/123456` | `GetMessage(user_id: "me" message_id:

"123456")`

## Rules for HTTP mapping

1. Leaf request fields (recursive expansion nested messages in the request

message) are classified into three categories:

- Fields referred by the path template. They are passed via the URL path.

- Fields referred by the [HttpRule.body][google.api.HttpRule.body]. They are passed via the HTTP

request body.

- All other fields are passed via the URL query parameters, and the

parameter name is the field path in the request message. A repeated

field can be represented as multiple query parameters under the same

name.

2. If [HttpRule.body][google.api.HttpRule.body] is "*", there is no URL query parameter, all fields

are passed via URL path and HTTP request body.

3. If [HttpRule.body][google.api.HttpRule.body] is omitted, there is no HTTP request body, all

fields are passed via URL path and URL query parameters.

### Path template syntax

Template = "/" Segments [ Verb ] ;

Segments = Segment { "/" Segment } ;

Segment = "*" | "**" | LITERAL | Variable ;

Variable = "{" FieldPath [ "=" Segments ] "}" ;

FieldPath = IDENT { "." IDENT } ;

Verb = ":" LITERAL ;

The syntax `*` matches a single URL path segment. The syntax `**` matches

zero or more URL path segments, which must be the last part of the URL path

except the `Verb`.

The syntax `Variable` matches part of the URL path as specified by its

template. A variable template must not contain other variables. If a variable

matches a single path segment, its template may be omitted, e.g. `{var}`

is equivalent to `{var=*}`.

The syntax `LITERAL` matches literal text in the URL path. If the `LITERAL`

contains any reserved character, such characters should be percent-encoded

before the matching.

If a variable contains exactly one path segment, such as `"{var}"` or

`"{var=*}"`, when such a variable is expanded into a URL path on the client

side, all characters except `[-_.~0-9a-zA-Z]` are percent-encoded. The

server side does the reverse decoding. Such variables show up in the

[Discovery

Document](https://developers.google.com/discovery/v1/reference/apis) as

`{var}`.

If a variable contains multiple path segments, such as `"{var=foo/*}"`

or `"{var=**}"`, when such a variable is expanded into a URL path on the

client side, all characters except `[-_.~/0-9a-zA-Z]` are percent-encoded.

The server side does the reverse decoding, except "%2F" and "%2f" are left

unchanged. Such variables show up in the

[Discovery

Document](https://developers.google.com/discovery/v1/reference/apis) as

`{+var}`.

## Using gRPC API Service Configuration

gRPC API Service Configuration (service config) is a configuration language

for configuring a gRPC service to become a user-facing product. The

service config is simply the YAML representation of the `google.api.Service`

proto message.

As an alternative to annotating your proto file, you can configure gRPC

transcoding in your service config YAML files. You do this by specifying a

`HttpRule` that maps the gRPC method to a REST endpoint, achieving the same

effect as the proto annotation. This can be particularly useful if you

have a proto that is reused in multiple services. Note that any transcoding

specified in the service config will override any matching transcoding

configuration in the proto.

Example:

http:

rules:

# Selects a gRPC method and applies HttpRule to it.

- selector: example.v1.Messaging.GetMessage

get: /v1/messages/{message_id}/{sub.subfield}

## Special notes

When gRPC Transcoding is used to map a gRPC to JSON REST endpoints, the

proto to JSON conversion must follow the [proto3

specification](https://developers.google.com/protocol-buffers/docs/proto3#json).

While the single segment variable follows the semantics of

[RFC 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.2 Simple String

Expansion, the multi segment variable **does not** follow RFC 6570 Section

3.2.3 Reserved Expansion. The reason is that the Reserved Expansion

does not expand special characters like `?` and `#`, which would lead

to invalid URLs. As the result, gRPC Transcoding uses a custom encoding

for multi segment variables.

The path variables **must not** refer to any repeated or mapped field,

because client libraries are not capable of handling such variable expansion.

The path variables **must not** capture the leading "/" character. The reason

is that the most common use case "{var}" does not capture the leading "/"

character. For consistency, all path variables must share the same behavior.

Repeated message fields must not be mapped to URL query parameters, because

no client library can support such complicated mapping.

If an API needs to use a JSON array for request or response body, it can map

the request or response body to a repeated field. However, some gRPC

Transcoding implementations may not support this feature.

File-level Extensions

Link

LinkTimers

Payload

PublisherConfig

SubscriberConfig

DiagnosticsService

Methods with HTTP bindings

BatchDownloadFileChunksRequest

BatchDownloadFileChunksResponse

Configuration

Configuration of server.

FileDescription

File information.

FileDescriptions

FileDownloadResponse

Response from file download request.

FileUploadChunkRequest

Request for file chunk upload.

Divide file in chunks of n bytes, where recommend n is 500000 bytes.

SHA256 which is part of FileDescription only needs to be submitted in the

last chunk.

FileUploadRequest

Parameters for a file upload.

SHA256 which is part of FileDescription only needs to be submitted in the

last chunk.

FileUploadResponse

Response from file or file chunk upload.

License

License data.

LicenseInfo

Server license information.

PropertyValue

ReloadMessage

Response from reload request.

LicenseStatus

Type for license status.

SystemService

Handle configuration of the RemotiveBroker server.

Methods with HTTP bindings

ClientId

Identifier for client. Used in subscribe and publish. Subscriptions will not

receive updates from publish calls with the same ClientId.

E2e

Information about E2E configuration.

Empty

Symbolic message representing no argument needed or provided.

FrameInfo

Information about a frame and it's signals.

Frames

Collection of information for several frames.

Group

Group inside of frame.

MetaData

Collection of all meta data for a signal.

RemotiveBroker support several databases. The following attributes are read

from the database running on the RemotiveBroker.

MetaData.NamedValuesEntry

Multiplex

Multiplexing information.

Some signal databases allow "multiplexing" or "unions" in their frame

information. IF a signal is in `select` mode, the value of the signal will

act as a filter for signals which are in `filter` mode.

NameSpace

Identifier for a name space.

NetworkInfo

Information about network

SignalId

Identifier for a signal.

SignalInfo

Information about a signal. Including name and all meta data fields.

E2eProfile

Supported E2E profiles.

CountByFrameId

FramesDistribution

FramesDistributionConfig

PublisherConfig

Parameters for publishing values.

Signal

Signal with value.

SignalIds

List of signal identifiers

Signals

Signals with values

SubscriberConfig

Parameters for subscription.

SubscriberWithScriptConfig

NetworkService

Signal publish, subscribe and read.

Methods with HTTP bindings

Scalar Value Types