На этой странице представлена справочная документация по конечным точкам API генератора конфигурации метрик (MCG).
Обзор конечных точек
В следующих разделах подробно описаны доступные в MCG API-интерфейсы.
Конфигурация метрик
-
POST /api/v1/generate_metrics_config: Создает экземплярMetricsConfigна основе сведений о запросе на настройку метрик. -
POST /api/v1/get_file_descriptor_set: Возвращает дескрипторы файлов для заданногоMetricsConfigдля декодирования отчетов. -
POST /api/v1/validate_metrics_config: Проверяет переданныйMetricsConfig, возвращая список всех ошибок проверки.
Каталоги автомобильных сигнальных устройств
-
POST /api/v1/vs/: Создать новый или обновить существующий каталог сигналов транспортного средства. -
GET /api/v1/vs/: Отображение всех метаданных каталога сигналов транспортных средств. -
DELETE /api/v1/vs/{version}: Удалить указанный каталог сигналов транспортного средства.
Статус обслуживания
-
GET /health: Проверить состояние сервиса.
Типы содержимого Protobuf
Несколько API-интерфейсов принимают или возвращают данные в формате Protocol Buffer (protobuf). Используются два типа содержимого:
-
application/x-protobuf: Указывает данные protobuf в двоичном формате. Этот формат эффективен для межмашинной связи, но не является удобочитаемым для человека. -
text/x-protobuf: Указывает данные protobuf в текстовом формате, удобочитаемом для человека и полезном для отладки или ручной проверки.
Если конечная точка поддерживает несколько форматов protobuf для запроса или ответа, используйте заголовок Content-Type для указания формата данных запроса и заголовок Accept для указания выбранного формата данных ответа. Например:
-
-H 'Content-Type: application/x-protobuf' -
-H 'Accept: text/x-protobuf'
Вызовите API
В примерах на этой странице для вызова REST API используется curl , и предполагается, что вы установили переменную среды SERVICE_URL , указывающую на хост, где развернут MCG. При локальном запуске это обычно http://localhost:8005 .
Чтобы выбрать удаленный экземпляр Cloud Run, установите SERVICE_URL с помощью gcloud . Затем добавьте заголовок авторизации с токеном идентификации OpenID Connect (OIDC) к вашей команде curl :
SERVICE_URL=$(gcloud run services describe mcg-service --region=<var label="Google Cloud region">GCP_REGION</var> --format='value(status.url)')
# Authorization header to append to curl command:
-H "Authorization: Bearer $(gcloud auth print-identity-token)"
Конфигурация метрик
В этом разделе описаны конечные точки для генерации и проверки конфигураций метрик.
POST /api/v1/generate_metrics_config
Создайте экземпляр MetricsConfig на основе сведений о запросе на настройку метрик. Этот процесс включает проверку, и если генерация не удается из-за нарушений схемы, недопустимых ссылок, циклических зависимостей или других проблем, API возвращает список сведений об ошибке.
| Сведения о конечной точке | |
|---|---|
| Параметры запроса | ignore_validation : booleanНеобязательный параметр. Если true , игнорировать ошибки проверки и вернуть MetricsConfig . |
| Текст запроса | В теле запроса должны содержаться подробные сведения о запросе на настройку метрик в формате JSON. |
| Ответ об успехе | Тело ответа содержит сообщение MetricsConfig в формате application/x-protobuf или text/x-protobuf .Заголовок Metrics-Config-Size содержит размер конфигурации в байтах. |
| Пример | curl -H "Content-Type: application/json" \ -H "Accept: text/x-protobuf" \ --data-binary @PATH_TO_METRICS_CONFIG_JSON \ "$SERVICE_URL/api/v1/generate_metrics_config" |
POST /api/v1/get_file_descriptor_set
Возвращает дескрипторы файлов для заданного MetricsConfig для декодирования отчетов.
| Сведения о конечной точке | |
|---|---|
| Текст запроса | Тело запроса должно содержать сообщение android.sdv.telemetry.MetricsConfig в формате application/x-protobuf или text/x-protobuf . |
| Ответ об успехе | В теле ответа содержится сообщение google.protobuf.FileDescriptorSet в формате application/x-protobuf или text/x-protobuf . |
| Пример | curl -H "Content-Type: application/x-protobuf" \ -H "Accept: application/x-protobuf" \ --data-binary @PATH_TO_METRICS_CONFIG_PB \ "$SERVICE_URL/api/v1/get_file_descriptor_set" |
POST /api/v1/validate_metrics_config
Проверьте предоставленный MetricsConfig , вернув список всех ошибок проверки.
| Сведения о конечной точке | |
|---|---|
| Параметры запроса | return_config : booleanНеобязательный параметр. Если true , возвращает MetricsConfig после успешной проверки. |
| Текст запроса | Тело запроса должно содержать сообщение android.sdv.telemetry.MetricsConfig в формате application/x-protobuf или text/x-protobuf . |
| Ответ об успехе | Тело ответа содержит пустой объект (по умолчанию) или MetricsConfig (если return_config равно true ).Заголовок Metrics-Config-Size содержит размер конфигурации в байтах. |
| Пример | curl -H "Content-Type: application/json" \ -H "Accept: application/json" \ --data-binary @PATH_TO_METRICS_CONFIG_JSON \ "$SERVICE_URL/api/v1/validate_metrics_config" |
Каталоги автомобильных сигнальных устройств
В этом разделе описываются конечные точки для управления каталогами сигналов транспортных средств.
POST /api/v1/vs/
Создать новый или обновить существующий каталог автомобильных сигналов.
| Сведения о конечной точке | |
|---|---|
| Текст запроса | Тело запроса должно содержать JSON-объект со строкой version и закодированным в base64 FileDescriptorSet для vehicle_signals . { "version": "string", "vehicle_signals": "string" } |
| Ответ об успехе | В случае успеха API возвращает application/json с указанием версии каталога, который был добавлен или обновлен: {"version": "string"} |
| Пример | Инструкции по генерации FileDescriptorSet в кодировке base64 для поля vehicle_signals см. в разделе «Каталоги сигналов транспортных средств» . curl -H "Content-Type: application/json" \ --data-binary @- "$SERVICE_URL/api/v1/vs/" << EOF { "version": "v1.0", "vehicle_signals": "VEHICLE_SIGNALS_BASE64" } EOF |
GET /api/v1/vs/
Перечислите все метаданные каталога автомобильных сигналов.
| Сведения о конечной точке | |
|---|---|
| Ответ об успехе | В случае успеха API возвращает application/json , содержащий список версий каталога: {"versions": [{"version": "string"}]} |
| Пример | curl "$SERVICE_URL/api/v1/vs/" |
Удалить /api/v1/vs/{version}
Удалите указанный каталог сигналов транспортного средства.
| Сведения о конечной точке | |
|---|---|
| Параметры пути | version : stringОбязательно. Идентификатор каталога сигналов транспортного средства для удаления, указанный в поле version POST-запроса. |
| Ответ об успехе | В случае успеха API возвращает application/json с версией каталога, который был удален: {"version": "string"} |
| Пример | curl --request DELETE "$SERVICE_URL/api/v1/vs/v1.0" |
Статус обслуживания
В этом разделе описаны конечные точки для проверки работоспособности сервисов.
GET /health
Проверьте работоспособность сервиса.
| Сведения о конечной точке | |
|---|---|
| Ответ об успехе | Если служба исправна, она возвращает код состояния 200 OK . |
| Пример | curl "$SERVICE_URL/health" |
Ответы об ошибках
Когда вызов API приводит к ошибке ( HTTP status 4xx или 5xx ), тело ответа содержит объект ошибки со следующей структурой:
{
"error": {
"code": 400,
"status": "INVALID_ARGUMENT",
"message": "Request validation failed",
"details": [
{
"@type": "type.googleapis.com/google.rpc.BadRequest",
"fieldViolations": [
{
"field": "fieldName",
"description": "error description"
}
]
}
]
}
}
| Поля ошибок | |
|---|---|
code | int32Код состояния HTTP (например, 400 , 404 или 500 ). |
status | stringКанонический код состояния RPC Google (например, INVALID_ARGUMENT , NOT_FOUND или INTERNAL ). |
message | stringСообщение об ошибке на английском языке, предназначенное для разработчиков. |
details | Array<object>Массив объектов, содержащих дополнительные сведения об ошибке, идентифицируемых по их члену @type . |