Filtros

La API de REST de Ad Manager admite el filtrado de métodos List. La sintaxis de la cadena de filtro se define de manera formal en la gramática de EBNF.

Para comenzar, aquí hay algunos ejemplos de casos de uso comunes.

Ejemplo Significado
orders.updateTime > "2024-01-01T00:00:00-5:00" Se muestran los pedidos con un updateTime después del 1 de enero de 2024 en la zona horaria estándar del este.
lineItems.targeting.geoTargeting.targetedGeoIds:2840 Muestra una lista de las líneas de pedido con una segmentación geográfica que contiene Estados Unidos (ID de segmentación geográfica 2480).
lineItems.displayName = "*_interstitial" Muestra una lista de las líneas de pedido que tienen un nombre visible que termina con la string _interstitial
orders.displayName = "*video*" Muestra una lista de los pedidos que tienen un nombre visible que contiene la string video
displayName:"video" Enumera los pedidos que tienen un nombre visible que contiene la string video (sintaxis alternativa).

Literales

Un valor literal vacío (ejemplos: 42, Hugo) es un valor con el que se debe comparar. Los literales que aparecen solos se comparan de forma parcial con todos los campos admitidos en un recurso. Los recursos documentan qué campos se consideran para buscar coincidencias en el método list. Esta función se puede comparar con la búsqueda universal en la IU de Ad Manager, pero se limita a un solo tipo de recurso.

Los literales de string que contienen espacios deben encerrarse entre comillas dobles (por ejemplo: "Foo bar"). No se pueden usar comillas simples para unir literales de string.

Operadores lógicos

La API de REST de Ad Manager admite los operadores binarios AND y OR.

Operador Ejemplo Significado
AND a AND b Es verdadero si a y b son verdaderos.
OR a OR b OR c Es verdadero si alguno de los valores a, b o c es verdadero.

Operadores de negociación

La API de REST de Ad Manager proporciona los operadores unarios NOT y -. Estos se pueden usar indistintamente.

Operador Ejemplo Significado
NOT NOT a Es verdadero si a no es verdadero.
- -a Es verdadero si a no es verdadero.

Operadores de comparación

La API de REST de Ad Manager admite los operadores de comparación binaria =, !=, <, >, <= y >= para los campos de string, numéricos, marca de tiempo y duración.

Operador Ejemplo Significado
= a = true Es verdadero si a es verdadero.
!= a != 42 Verdadero, a menos que a sea igual a 42.
< a < 42 Es verdadero si a es un valor numérico inferior a 42.
> a > "foo" Es verdadero si a se ordena de forma léxica después de "foo".
<= a <= "foo" Es verdadero si a es "foo" o léxicamente antes de él.
>= a >= 42 Verdadero si a es un valor numérico de 42 o superior.

Debido a que los filtros se aceptan como cadenas de consulta, se produce la conversión de tipos para traducir la cadena al valor adecuado de tipado fuerte:

  • Las cadenas esperan comillas dobles. Ejemplo: "Foo bar".
  • Las enumeraciones esperan la representación de la string de la enum (distingue mayúsculas de minúsculas).
  • Los booleanos esperan valores literales true y false.
  • Los números esperan las representaciones estándar de números enteros o de número de punto flotante. En el caso de los números de punto flotante, se admiten los exponentes. Ejemplo: 2.997e9.
  • Las duraciones esperan una representación numérica seguida de un sufijo s (para segundos). Ejemplos: "20s", "1.2s".
  • Las marcas de tiempo esperan una string con formato RFC-3339. Ejemplo: "2012-04-21T11:30:00-04:00". Se admiten las compensaciones UTC.

Comodines

Cuando se comparan strings para determinar la igualdad, la API de REST de Ad Manager admite comodines que usan el carácter *.

Ejemplo Significado
a = "*.foo" Es verdadero si a termina con “.foo”.

Operador transversal

La API de REST de Ad Manager admite el operador ., que indica el recorrido a través de un mensaje, un mapa o un struct.

Ejemplo Significado
a.b = true Es verdadero si a tiene un campo booleano b que es verdadero.
a.b > 42 Verdadero si a tiene un campo b numérico mayor que 42.
a.b.c = "foo" Verdadero si a.b tiene un campo c de string que es "foo".

El recorrido se escribe con los nombres de campo del recurso. Los servicios individuales pueden especificar un subconjunto de campos que sean compatibles con el recorrido.

Tiene operador

La API de REST de Ad Manager admite el operador :, que significa "has". Se puede usar con colecciones (campos repetidos o mapas), mensajes y strings, y se comporta de forma ligeramente diferente en cada caso.

Consulta los campos de string para ver si la string contiene una substring coincidente:

Ejemplo Significado
r.displayName:"_250x250" Es verdadero si el campo de cadena r.displayName contiene la subcadena _250x250.

Consulta de campos repetidos para ver si la estructura repetida contiene un elemento coincidente:

Ejemplo Significado
r:42 Es verdadero si r contiene 42.
r.foo:42 Es verdadero si r contiene un elemento e tal que e.foo = 42.

Los mapas, los structs y los mensajes pueden consultar tanto la presencia de un campo en el mapa como un valor específico:

Ejemplo Significado
m:foo Verdadero si m contiene la clave "foo".
m.foo:* Verdadero si m contiene la clave "foo".
m.foo:42 Es verdadero si m.foo es 42.

Cuando se recorren mensajes, se considera que un campo solo está presente si tiene un valor no predeterminado.

Limitaciones

Los servicios individuales pueden especificar más estructura o limitaciones para las consultas de filtro además de lo que se define aquí.

Pedidos

La API de REST de Ad Manager admite pedidos en métodos List. La sintaxis de los campos orderBy es una lista de nombres de campos separada por comas. Por ejemplo: "foo,bar".

El orden predeterminado es ascendente. Si quieres especificar el orden descendente para un campo, agrega un sufijo " desc". Por ejemplo: "foo desc, bar".

Se ignoran los caracteres de espacio redundantes en la sintaxis. Los valores "foo, bar desc", " foo , bar desc " y "foo,bar desc" son equivalentes.

Los subcampos se especifican con el operador de recorrido. Por ejemplo, foo.bar o address.street.