La API de Media Translation está obsoleta y ya no estará disponible en Google Cloud después del 1 de julio de 2024. Puedes replicar la funcionalidad de la API de Media Translation mediante una combinación de otros servicios de Google Cloud, como Cloud Speech-to-Text y la API de Cloud Translation.

Package google.rpc

Índice

Code (enum)
Status (mensaje)

Código

Los códigos de error canónicos para las API de gRPC.

A veces, es posible que se apliquen varios códigos de error. Los servicios deben mostrar el código de error más específico que corresponda. Por ejemplo, es preferible OUT_OF_RANGE en lugar de FAILED_PRECONDITION si se aplican ambos códigos. Del mismo modo, prefiere NOT_FOUND o ALREADY_EXISTS en lugar de FAILED_PRECONDITION.

Enums
`OK`	No es un error, que se muestra con éxito. Asignación HTTP: 200 OK
`CANCELLED`	La operación se canceló (por lo general, la cancela el emisor). Asignación HTTP: 499 Solicitudes cerradas por el cliente
`UNKNOWN`	Error desconocido Por ejemplo, este error puede mostrarse cuando un valor `Status` recibido de otro espacio de direcciones pertenece a un espacio de error desconocido en este espacio de direcciones. Además, los errores generados por API que no muestran suficiente información sobre el error pueden convertirse en este error. Asignación HTTP: Error interno del servidor 500
`INVALID_ARGUMENT`	El cliente especificó un argumento no válido. Ten en cuenta que esto difiere de `FAILED_PRECONDITION`. `INVALID_ARGUMENT` indica los argumentos que son problemáticos sin importar el estado del sistema (p.ej., un nombre de archivo con formato incorrecto). Asignación HTTP: 400 Solicitud incorrecta
`DEADLINE_EXCEEDED`	El plazo venció antes de que la operación se pudiera completar. En el caso de las operaciones que cambian el estado del sistema, es probable que se muestre este error incluso si la operación se completó correctamente. Por ejemplo, una respuesta correcta desde un servidor podría haberse retrasado lo suficiente como para que el plazo venciera. Asignación HTTP: Tiempo de espera de la puerta de enlace 504
`NOT_FOUND`	No se encontró alguna entidad solicitada (p. ej., un archivo o un directorio). Nota para los desarrolladores de servidores: si se niega una solicitud a una clase completa de usuarios, como el lanzamiento gradual de funciones o una lista de permisos no documentada, se puede usar `NOT_FOUND`. Si se niega una solicitud para algunos usuarios dentro de una clase de usuarios, como el control de acceso basado en usuarios, se debe usar `PERMISSION_DENIED` Asignación HTTP: 404 No encontrado
`ALREADY_EXISTS`	La entidad que un cliente intentó crear (p.ej., un archivo o un directorio) ya existe. Asignación HTTP: 409 Conflicto
`PERMISSION_DENIED`	El emisor de la llamada no tiene permiso para ejecutar la operación especificada. No se debe usar `PERMISSION_DENIED` para los rechazos causados por el agotamiento de algún recurso (en su lugar, usa `RESOURCE_EXHAUSTED` para esos errores). No se debe usar `PERMISSION_DENIED` si no se puede identificar al emisor (en su lugar, usa `UNAUTHENTICATED` para esos errores). Este código de error no sugiere que la solicitud sea válida o que la entidad solicitada exista o satisfaga otras condiciones previas. Asignación HTTP: 403 Prohibido
`UNAUTHENTICATED`	La solicitud no tiene credenciales de autenticación válidas para la operación. Asignación HTTP: 401 No autorizado
`RESOURCE_EXHAUSTED`	Algunos recursos se agotaron, tal vez una cuota por usuario, o tal vez se agotó el espacio de todo el sistema de archivos. Asignación HTTP: 429 Demasiadas solicitudes
`FAILED_PRECONDITION`	La operación se rechazó debido a que el sistema no se encuentra en un estado necesario para la ejecución de la operación. Por ejemplo, el directorio que se borrará no está vacío, se aplicará una operación rmdir a un directorio que no sea de directorio, etcétera. Los implementadores de servicios pueden usar los siguientes lineamientos para decidir entre `FAILED_PRECONDITION`, `ABORTED` y `UNAVAILABLE`: (a) Usa `UNAVAILABLE` si el cliente puede reintentar solo la llamada con errores. (b) Usa `ABORTED` si el cliente debe reintentar en un nivel superior. Por ejemplo, cuando falla una prueba y un conjunto especificado por el cliente, lo que indica que el cliente debe reiniciar una secuencia de lectura, modificación y escritura. (c) Usa `FAILED_PRECONDITION` si el cliente no debe volver a intentar hasta que el estado del sistema se haya corregido de forma explícita. Por ejemplo, si un "rmdir" falla porque el directorio no está vacío, se debe mostrar `FAILED_PRECONDITION`, ya que el cliente no debe reintentar, a menos que se borren los archivos del directorio. Asignación HTTP: 400 Solicitud incorrecta
`ABORTED`	La operación se anuló, generalmente debido a un problema de simultaneidad, como una falla en la verificación del secuenciador o la anulación de la transacción. Consulta los lineamientos anteriores para decidir entre `FAILED_PRECONDITION`, `ABORTED` y `UNAVAILABLE`. Asignación HTTP: 409 Conflicto
`OUT_OF_RANGE`	La operación se intentó fuera del rango válido. Por ejemplo, buscar o leer el final del archivo. A diferencia de `INVALID_ARGUMENT`, este error indica un problema que se puede solucionar si cambia el estado del sistema. Por ejemplo, un sistema de archivos de 32 bits generará `INVALID_ARGUMENT` si se le pide que lea en un desplazamiento que no esté en el rango [0,2^32-1], pero generará `OUT_OF_RANGE` si se le pide leer. desde un desplazamiento después del tamaño de archivo actual Hay una leve superposición entre `FAILED_PRECONDITION` y `OUT_OF_RANGE`. Recomendamos usar `OUT_OF_RANGE` (el error más específico) cuando se aplique para que los emisores que iteran a través de un espacio puedan buscar con facilidad un error `OUT_OF_RANGE` a fin de detectar cuando finalicen. Asignación HTTP: 400 Solicitud incorrecta
`UNIMPLEMENTED`	La operación no se implementó, no se admite o no está habilitada en este servicio. Asignación HTTP: 501 No implementado
`INTERNAL`	Errores internos. Esto significa que algunos invariantes que espera el sistema subyacente están rotos. Este código de error está reservado para errores graves. Asignación HTTP: Error interno del servidor 500
`UNAVAILABLE`	El servicio no está disponible actualmente. Lo más probable es que esta sea una condición transitoria y que se pueda corregir si vuelves a intentar una retirada. Ten en cuenta que no siempre es seguro reintentar operaciones no idempotentes. Consulta los lineamientos anteriores para decidir entre `FAILED_PRECONDITION`, `ABORTED` y `UNAVAILABLE`. Asignación HTTP: 503 Servicio no disponible
`DATA_LOSS`	Daño o pérdida de datos no recuperable. Asignación HTTP: Error interno del servidor 500

Estado

El tipo de Status define un modelo de error lógico que es adecuado para entornos de programación diferentes, incluidas las API de REST y las API de RPC. Lo usa gRPC. Cada mensaje Status contiene tres datos: código de error, mensaje de error y detalles del error.

Puedes obtener más información sobre este modelo de error y cómo trabajar con él en la guía de diseño de API.

Campos

Campos
`code`	`int32` El código de estado, que debe ser un valor enum de `google.rpc.Code`.
`message`	`string` Un mensaje de error dirigido al desarrollador, que debe estar en inglés. Cualquier mensaje de error dirigido al usuario debe localizarse y enviarse al campo `google.rpc.Status.details`; o el cliente debe localizarlo.
`details[]`	`Any` Una lista de mensajes que contienen los detalles del error. Hay un conjunto común de tipos de mensajes para que usen las API.

code

int32

El código de estado, que debe ser un valor enum de google.rpc.Code.

message

string

Un mensaje de error dirigido al desarrollador, que debe estar en inglés. Cualquier mensaje de error dirigido al usuario debe localizarse y enviarse al campo google.rpc.Status.details; o el cliente debe localizarlo.

details[]

Any

Una lista de mensajes que contienen los detalles del error. Hay un conjunto común de tipos de mensajes para que usen las API.