Package google.rpc

Índice

BadRequest

Describe las infracciones de una solicitud de un cliente. Este tipo de error se centra en los aspectos sintácticos de la solicitud.

Campos
field_violations[]

FieldViolation

Describe todas las infracciones de una solicitud de un cliente.

FieldViolation

Tipo de mensaje que se usa para describir un solo campo de solicitud incorrecto.

Campos
field

string

Ruta que lleva a un campo del cuerpo de la solicitud. El valor será una secuencia de identificadores separados por puntos que identifican un campo de búfer de protocolo.

Ten en cuenta lo siguiente:

message CreateContactRequest {
  message EmailAddress {
    enum Type {
      TYPE_UNSPECIFIED = 0;
      HOME = 1;
      WORK = 2;
    }

    optional string email = 1;
    repeated EmailType type = 2;
  }

  string full_name = 1;
  repeated EmailAddress email_addresses = 2;
}

En este ejemplo, en el proto field podría tomar uno de los siguientes valores:

  • full_name por una infracción en el valor full_name
  • email_addresses[1].email por una infracción en el campo email del primer mensaje email_addresses
  • email_addresses[3].type[2] por una infracción en el segundo type valor del tercer email_addresses mensaje.

En JSON, los mismos valores se representan de la siguiente manera:

  • fullName por una infracción en el valor fullName
  • emailAddresses[1].email por una infracción en el campo email del primer mensaje emailAddresses
  • emailAddresses[3].type[2] por una infracción en el segundo type valor del tercer emailAddresses mensaje.
description

string

Descripción de por qué el elemento de la solicitud es incorrecto.
reason

string

El motivo del error a nivel de campo. Es un valor constante que identifica la causa próxima del error a nivel de campo. Debe identificar de forma única el tipo de FieldViolation en el ámbito de google.rpc.ErrorInfo.domain. Debe tener 63 caracteres como máximo y coincidir con la expresión regular [A-Z][A-Z0-9_]+[A-Z0-9], que representa UPPER_SNAKE_CASE.
localized_message

LocalizedMessage

Proporciona un mensaje de error localizado para errores a nivel de campo que se puede devolver al consumidor de la API.

Código

Códigos de error canónicos de las APIs de gRPC.

En ocasiones, pueden aplicarse varios códigos de error. Los servicios deben devolver el código de error más específico que corresponda. Por ejemplo, dale preferencia a OUT_OF_RANGE sobre FAILED_PRECONDITION si se aplican ambos códigos. Del mismo modo, prefiere NOT_FOUND o ALREADY_EXISTS en lugar de FAILED_PRECONDITION.

Enumeraciones
OK

No es un error, sino que se devuelve cuando la operación se realiza correctamente.

Asignación HTTP: 200 OK
CANCELLED

La operación se canceló. Normalmente, lo hizo la persona que llama.

Asignación HTTP: 499 El cliente cerró la petición
UNKNOWN

Error desconocido. Por ejemplo, este error puede devolverse cuando un valor Status recibido de otro espacio de direcciones pertenece a un espacio de errores que no se conoce en este espacio de direcciones. Asimismo, los errores generados por las API que no devuelven suficiente información del error pueden convertirse a este error.

Asignación HTTP: 500 Error interno del servidor
INVALID_ARGUMENT

El cliente especificó un argumento no válido. Ten en cuenta que es diferente de FAILED_PRECONDITION. INVALID_ARGUMENT indica argumentos que son problemáticos independientemente del estado del sistema (por ejemplo, un nombre de archivo con formato incorrecto).

Asignación HTTP: 400 Petición incorrecta
DEADLINE_EXCEEDED

El tiempo de espera se ha agotado antes de que la operación se completara. En el caso de operaciones que cambian el estado del sistema, puede que se devuelva este error incluso si la operación se ha completado correctamente. Por ejemplo, una respuesta correcta de un servidor podría haberse retrasado el tiempo suficiente para que se agote el tiempo de espera.

Asignación HTTP: 504 Tiempo de espera de la pasarela
NOT_FOUND

No se encontró ninguna entidad solicitada (por ejemplo, un archivo o un directorio).

Nota para los desarrolladores de servidores: si se deniega una solicitud para toda una clase de usuarios (por ejemplo, en el caso de un lanzamiento gradual de una función o de una lista de permitidos no documentada), se puede usar NOT_FOUND. Si se deniega una solicitud a algunos usuarios 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 ha intentado crear (por ejemplo, un archivo o un directorio) ya existe.

Asignación HTTP: 409 Conflicto
PERMISSION_DENIED

La persona que llama no tiene permiso para ejecutar la operación especificada. PERMISSION_DENIED no debe usarse para los rechazos provocados por el agotamiento de recursos (en su lugar, utiliza RESOURCE_EXHAUSTED para esos errores). No se debe usar PERMISSION_DENIED si no se puede identificar al llamante (en su lugar, usa UNAUTHENTICATED para esos errores). Este código de error no implica que la petición sea válida o que la entidad solicitada exista o cumpla otras condiciones previas.

Asignación HTTP: 403 Prohibido
UNAUTHENTICATED

La petición no cuenta con credenciales de autenticación válidas para la operación.

Asignación HTTP: 401 No autorizado
RESOURCE_EXHAUSTED

Algunos recursos se han agotado; es posible que una cuota por usuario, o tal vez todo el sistema de archivos, esté sin espacio.

Asignación HTTP: 429 Demasiadas peticiones
FAILED_PRECONDITION

Se ha rechazado la operación porque el sistema no se encuentra en un estado requerido para la ejecución de dicha operación. Por ejemplo, el directorio que se va a eliminar no está vacío, una operación rmdir no se aplica a un directorio, etc.

Los implementadores de servicios pueden usar las siguientes directrices para decidir entre FAILED_PRECONDITION, ABORTED y UNAVAILABLE: a) Usa UNAVAILABLE si el cliente puede volver a intentar solo la llamada fallida. b) Usa ABORTED si el cliente debe volver a intentarlo a un nivel superior. Por ejemplo, cuando falla una prueba y un conjunto especificados por el cliente, lo que indica que el cliente debe reiniciar una secuencia de lectura-modificación-escritura. c) Usa FAILED_PRECONDITION si el cliente no debe volver a intentarlo hasta que se haya corregido explícitamente el estado del sistema. Por ejemplo, si se produce un error en "rmdir" porque el directorio no está vacío, se debe devolver FAILED_PRECONDITION, ya que el cliente no debe volver a intentarlo a menos que se eliminen los archivos del directorio.

Asignación HTTP: 400 Petición incorrecta
ABORTED

La operación se anuló, normalmente debido a un problema de simultaneidad, como un error en la verificación del secuenciador o la cancelación de una transacción.

Consulta las directrices anteriores para decidir entre FAILED_PRECONDITION, ABORTED y UNAVAILABLE.

Asignación HTTP: 409 Conflicto
OUT_OF_RANGE

Se intentó realizar la operación más allá del rango válido. Por ejemplo, buscando o leyendo más allá del final del archivo.

A diferencia de INVALID_ARGUMENT, este error indica un problema que puede corregirse si el estado del sistema cambia. 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 intervalo [0,2^32-1], pero generará OUT_OF_RANGE si se le pide que lea desde un desplazamiento posterior al tamaño del archivo actual.

Hay una pequeña superposición entre FAILED_PRECONDITION y OUT_OF_RANGE. Se recomienda usar OUT_OF_RANGE (el error más específico) cuando se aplique, de modo que las personas que llaman y repliquen a través de un espacio puedan buscar con facilidad un error de OUT_OF_RANGE para detectar que han acabado.

Asignación HTTP: 400 Petición incorrecta
UNIMPLEMENTED

La operación no se ha desplegado, no es compatible o no está habilitada en este servicio.

Asignación HTTP: 501 No desplegado
INTERNAL

Errores internos. Indica que se han roto algunas invariables previstas por el sistema. Este código de error se reserva para los errores graves.

Asignación HTTP: 500 Error interno del servidor
UNAVAILABLE

El servicio no está disponible en este momento. Es muy probable que se trate de una condición transitoria, que puede corregirse volviendo a intentarlo con una interrupción. Ten en cuenta que no siempre es seguro volver a intentar operaciones no idempotentes.

Consulta las directrices anteriores para decidir entre FAILED_PRECONDITION, ABORTED y UNAVAILABLE.

Asignación HTTP: 503 Servicio no disponible
DATA_LOSS

Datos dañados o pérdida irrecuperable de datos.

Asignación HTTP: 500 Error interno del servidor

LocalizedMessage

Proporciona un mensaje de error localizado que se puede devolver al usuario de forma segura y que se puede adjuntar a un error de RPC.

Campos
locale

string

La configuración regional utilizada según la especificación definida en https://www.rfc-editor.org/rfc/bcp/bcp47.txt. Por ejemplo: "en-US", "fr-CH", "es-MX".
message

string

Mensaje de error localizado en la configuración regional anterior.

Estado

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

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

Campos
code

int32

Código de estado, que debe ser un valor de enumeración de google.rpc.Code.
message

string

Un mensaje de error dirigido al desarrollador, que debe estar en inglés. Cualquier mensaje de error visible para el usuario debe localizarse y enviarse en el campo google.rpc.Status.details, o bien lo debe localizar el cliente.
details[]

Any

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