Apéndice de la guía de API de Registro de esquemas
Este documento proporciona información complementaria relacionada con el trabajo con Schema Registry API.
Uso de parámetros de consulta query
El Schema Registry admite el uso de parámetros de consulta para paginar y filtrar los resultados al enumerar recursos.
&).Paginación paging
Los parámetros de consulta más comunes para la paginación incluyen:
orderbyorderby=title ordenará los resultados por título en orden ascendente (A-Z). Adición de un - antes del valor del parámetro (orderby=-title) ordenará los elementos por título en orden descendente (Z-A).limitorderby parámetro, limit restringe el número máximo de elementos que deben devolverse para una solicitud determinada. Este parámetro no se puede utilizar sin un orderby parámetro presente.El
limit parámetro especifica un entero positivo (entre 0 y 500) as a indicio en cuanto al número máximo de elementos que deben devolverse. Por ejemplo, limit=5 devuelve solo cinco recursos de la lista. Sin embargo, este valor no se respeta estrictamente. El tamaño de respuesta real puede ser menor o mayor, ya que está limitado por la necesidad de proporcionar un funcionamiento fiable del start parámetro, si se proporciona uno.startorderby parámetro, start especifica dónde debe comenzar la lista de elementos subconfigurada. Este parámetro no se puede utilizar sin un orderby parámetro presente. Este valor se puede obtener del _page.next de una respuesta de lista y se utiliza para acceder a la siguiente página de resultados. Si la variable _page.next el valor es nulo, por lo que no hay ninguna página adicional disponible.Normalmente, este parámetro se omite para obtener la primera página de resultados. Después de eso,
start debe establecerse en el valor máximo de la propiedad de ordenación principal de la variable orderby campo recibido en la página anterior. A continuación, la respuesta de la API devuelve entradas que comienzan por las que tienen una propiedad de ordenación principal de orderby estrictamente mayor que (para ascendente) o estrictamente menor que (para descendente) el valor especificado.Por ejemplo, si la variable
orderby El parámetro se ha establecido en orderby=name,firstname, el start contendría un valor para el parámetro name propiedad. En este caso, si desea mostrar las 20 entradas siguientes de un recurso inmediatamente después del nombre "Miller", debe utilizar: ?orderby=name,firstname&start=Miller&limit=20.Filtro filtering
Puede filtrar los resultados utilizando la variable property , que se utiliza para aplicar un operador específico a una propiedad JSON determinada dentro de los recursos recuperados. Los operadores admitidos son:
==property=title==test!=property=title!=test<property=version<5>property=version>5<=property=version<=5>=property=version>=5property=titleproperty para filtrar grupos de campos de esquema por su clase compatible. Por ejemplo, property=meta:intendedToExtend==https://ns.adobe.com/xdm/context/profile devuelve solo los grupos de campos compatibles con XDM Individual Profile clase.Modo de compatibilidad compatibility
Experience Data Model (XDM) es una especificación documentada públicamente, impulsada por el Adobe de mejorar la interoperabilidad, la expresividad y la potencia de las experiencias digitales. El Adobe mantiene el código fuente y las definiciones XDM formales en una proyecto de código abierto en GitHub. Estas definiciones se escriben en notación estándar XDM, utilizando JSON-LD (notación de objetos JavaScript para datos vinculados) y esquema JSON como gramática para definir esquemas XDM.
Al consultar las definiciones de XDM formales en el repositorio público, puede ver que el XDM estándar difiere de lo que se ve en Adobe Experience Platform. Lo que está viendo en Experience Platform se denomina Modo de compatibilidad y proporciona una asignación sencilla entre XDM estándar y la forma en que se utiliza dentro de Platform.
Funcionamiento del modo de compatibilidad
El modo de compatibilidad permite que el modelo XDM JSON-LD funcione con una infraestructura de datos existente alterando los valores dentro del XDM estándar y manteniendo la semántica igual. Utiliza una estructura JSON anidada, que muestra los esquemas en un formato de árbol.
La principal diferencia entre el XDM estándar y el modo de compatibilidad es la eliminación del prefijo "xdm:" para los nombres de campo.
A continuación se muestra una comparación en paralelo que muestra campos relacionados con el cumpleaños (con atributos de "descripción" eliminados) tanto en el XDM estándar como en el modo de compatibilidad. Observe que los campos Modo de compatibilidad incluyen una referencia al campo XDM y su tipo de datos en los atributos "meta:xdmField" y "meta:xdmType".
¿Por qué es necesario el modo de compatibilidad?
Adobe Experience Platform está diseñado para trabajar con varias soluciones y servicios, cada uno con sus propios desafíos y limitaciones técnicas (por ejemplo, cómo gestionan ciertas tecnologías los caracteres especiales). Para superar estas limitaciones, se desarrolló el Modo de compatibilidad.
Más Experience Platform servicios que incluyen Catalog, Data Lake, y Real-Time Customer Profile use Compatibility Mode en lugar del XDM estándar. El Schema Registry La API también utiliza Compatibility Modey los ejemplos de este documento se muestran utilizando Compatibility Mode.
Vale la pena saber que se produce una asignación entre el XDM estándar y la forma en que se opera en Experience Platform, pero no debería afectar a su uso de Platform servicios.
El proyecto de código abierto está disponible, pero cuando se trata de interactuar con recursos a través de Schema RegistrySin embargo, los ejemplos de API de este documento proporcionan las prácticas recomendadas que debe conocer y seguir.