Realización de operaciones condicionales mediante la API web

Microsoft Dataverse proporciona compatibilidad con un conjunto de operaciones condicionales que dependen del mecanismo estándar de control de versiones de recursos HTTP conocido como ETags.

ETags

El protocolo HTTP define una etiqueta de entidad o ETag para abreviar, para identificar versiones específicas de un recurso. ETags son identificadores opacos cuyos valores exactos dependen de la implementación. Los valores ETag se producen en dos variedades: validación fuerte y débil. La validación segura indica que un recurso único, identificado por un URI específico, es idéntico en el nivel binario si su valor ETag correspondiente no cambia. La validación débil solo garantiza que la representación de recursos sea semánticamente equivalente para el mismo valor ETag.

Dataverse genera una propiedad de validación @odata.etag débil para cada instancia de entidad y esta propiedad se devuelve automáticamente con cada registro de entidad recuperado. Para obtener más información, consulte Recuperación de una fila de tabla mediante la API web.

encabezados If-Match e If-None-Match

Use encabezados If-Match e If-None-Match con valores ETag para comprobar si la versión actual de un recurso coincide con la que se recuperó por última vez, coincide con cualquier versión anterior o no coincide con ninguna versión. Estas comparaciones constituyen la base del soporte para operaciones condicionales. Dataverse proporciona ETags para admitir las recuperaciones condicionales, la simultaneidad optimista y las operaciones upsert limitadas.

Advertencia

El código de cliente no debe dar ningún significado al valor específico de una ETag, ni a ninguna relación aparente entre ETags más allá de la igualdad o desigualdad. Por ejemplo, no se garantiza que un valor ETag para una versión más reciente de un recurso sea mayor que el valor ETag de una versión anterior. Además, el algoritmo usado para generar nuevos valores ETag puede cambiar sin previo aviso entre las versiones de un servicio.

Recuperaciones condicionales

Etags le permiten optimizar las recuperaciones de registros cada vez que accede al mismo registro varias veces. Si ha recuperado previamente un registro, puede pasar el valor de ETag con el encabezado If-None-Match para solicitar los datos solo si han cambiado desde la última vez que se recuperaron. Si los datos han cambiado, la solicitud devuelve un estado HTTP de 200 OK con los datos más recientes en el cuerpo de la solicitud. Si los datos no cambian, se devuelve el código 304 Not Modified de estado HTTP para indicar que no se ha modificado el registro.

El siguiente par de mensajes de ejemplo devuelve datos de un registro de cuenta con un valor de accountid igual a 00000000-0000-0000-0000-000000000001 cuando los datos no han cambiado desde que se recuperaron por última vez cuando el valor de Etag era W/"468026".

Solicitud:

GET [Organization URI]/api/data/v9.2/accounts(00000000-0000-0000-0000-000000000001)?$select=accountcategorycode,accountnumber,creditonhold,createdon,numberofemployees,name,revenue   HTTP/1.1  
Accept: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0  
If-None-Match: W/"468026"  

Respuesta:

HTTP/1.1 304 Not Modified  
Content-Type: application/json; odata.metadata=minimal  
OData-Version: 4.0  

En las secciones siguientes se describen las limitaciones de uso de las recuperaciones condicionales.

La tabla debe tener habilitada la concurrencia optimista

Compruebe si una tabla tiene habilitada la simultaneidad optimista mediante la siguiente solicitud de API web. Las tablas que tienen habilitada la simultaneidad optimista tienen la propiedad EntityMetadata.IsOptimisticConcurrencyEnabled establecida en true.

GET [Organization URI]/api/data/v9.2/EntityDefinitions(LogicalName='<Entity Logical Name>')?$select=IsOptimisticConcurrencyEnabled

La consulta no debe incluir $expand

El Etag solo puede detectar si se ha cambiado el registro único que se está recuperando. Cuando se usa $expand en la consulta, es posible que se devuelvan más registros y no es posible detectar si se ha cambiado o no alguno de esos registros. Si la consulta incluye $expand, 304 Not Modified nunca se devuelve.

La consulta no debe incluir anotaciones

Cuando el Prefer: odata.include-annotations encabezado se incluye con una GET solicitud, 304 Not Modified nunca se devuelve. Los valores de las anotaciones pueden hacer referencia a valores de registros relacionados. Estos registros podrían haber cambiado y este cambio no se pudo detectar, por lo que sería incorrecto indicar que nada ha cambiado.

Limitar las operaciones upsert

Un upsert normalmente funciona creando un registro si no existe; de lo contrario, actualiza un registro existente. Sin embargo, los ETags se pueden usar para restringir aún más los upserts, ya sea para evitar las creaciones o para evitar las actualizaciones.

Evitar crear en upsert

Si va a actualizar los datos y existe alguna posibilidad de que el registro se haya eliminado intencionadamente, no querrá volver a crear el registro. Para evitar esto, agregue un If-Match encabezado a la solicitud con un valor de *.

Solicitud:

PATCH [Organization URI]/api/data/v9.2/accounts(00000000-0000-0000-0000-000000000001) HTTP/1.1  
Content-Type: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0  
If-Match: *  
  
{  
    "name": "Updated Sample Account ",  
    "creditonhold": true,  
    "address1_latitude": 47.639583,  
    "description": "This is the updated description of the sample account",  
    "revenue": 6000000,  
    "accountcategorycode": 2  
}  

Respuesta:

Si se encuentra el registro, obtendrá una respuesta normal con el estado 204 No Content. Cuando no se encuentra el registro, obtendrá la siguiente respuesta con el estado 404 Not Found.

HTTP/1.1 404 Not Found  
OData-Version: 4.0  
Content-Type: application/json; odata.metadata=minimal  
  
{  
 "error": {  
  "code": "",  
  "message": "account With Id = 00000000-0000-0000-0000-000000000001 Does Not Exist"
 }  
}  

Impedir la actualización en upsert

Si va a insertar datos, existe alguna posibilidad de que ya exista un registro con el mismo id valor en el sistema y es posible que no quiera actualizarlo. Para evitar esto, agregue un If-None-Match encabezado a la solicitud con un valor de "*".

Solicitud:

PATCH [Organization URI]/api/data/v9.2/accounts(00000000-0000-0000-0000-000000000001) HTTP/1.1  
Content-Type: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0  
If-None-Match: *  
  
{  
    "name": "Updated Sample Account ",  
    "creditonhold": true,  
    "address1_latitude": 47.639583,  
    "description": "This is the updated description of the sample account",  
    "revenue": 6000000,  
    "accountcategorycode": 2  
}  

Respuesta:
Si no se encuentra el registro, obtendrá una respuesta normal con el estado 204 No Content. Cuando se encuentra el registro, obtendrá la siguiente respuesta con el estado 412 Precondition Failed.

HTTP/1.1 412 Precondition Failed  
OData-Version: 4.0  
Content-Type: application/json; odata.metadata=minimal  
  
{  
  "error":{  
   "code":"",  
   "message":"A record with matching key values already exists."
  }  
}  

Aplicar simultaneidad optimista

Puede usar la simultaneidad optimista para detectar si se modificó un registro desde que se recuperó por última vez. Si el registro que piensa actualizar o eliminar ha cambiado en el servidor desde que lo recuperó, es posible que no desee completar la operación de actualización o eliminación. Al aplicar el patrón que se muestra aquí, puede detectar esta situación, recuperar la versión más reciente del registro y aplicar los criterios necesarios para volver a evaluar si desea volver a intentar la operación.

Aplicar simultaneidad optimista al eliminar

La siguiente solicitud de eliminación de una cuenta con accountid de 00000000-0000-0000-0000-000000000001 da error porque el valor de ETag enviado con el encabezado If-Match es diferente del valor actual. Si el valor coincide, se espera un estado 204 No Content.

Solicitud:

DELETE [Organization URI]/api/data/v9.2/accounts(00000000-0000-0000-0000-000000000001) HTTP/1.1  
If-Match: W/"470867"  
Accept: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0  

Respuesta:

HTTP/1.1 412 Precondition Failed  
Content-Type: application/json; odata.metadata=minimal  
OData-Version: 4.0  
  
{  
  "error":{  
    "code":"","message":"The version of the existing record doesn't match the RowVersion property provided." 
  }  
}  

Aplicar simultaneidad optimista al actualizar

Se produce un error en la siguiente solicitud de actualización para una cuenta con accountid de 00000000-0000-0000-0000-000000000001 porque el valor ETag enviado con la cabecera If-Match es diferente del valor actual. Si el valor coincide, se espera un estado 204 No Content.

Solicitud:

PATCH [Organization URI]/api/data/v9.2/accounts(00000000-0000-0000-0000-000000000001) HTTP/1.1  
If-Match: W/"470867"  
Accept: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0  
  
{"name":"Updated Account Name"}  

Respuesta:

HTTP/1.1 412 Precondition Failed  
Content-Type: application/json; odata.metadata=minimal  
OData-Version: 4.0  
  
{  
  "error":{  
    "code":"","message":"The version of the existing record doesn't match the RowVersion property provided."
  }  
}  

Consulte también

Ejemplo de operaciones condicionales de la API web (C#)
Ejemplo de operaciones condicionales de API web (JavaScript del lado cliente)
Realización de operaciones mediante la API web
Redacción de solicitudes HTTP y control de errores
Consultar datos utilizando la API web
Crear una fila de tabla usando la API web
Recuperar una fila de tabla usando la API web
Actualizar y eliminar filas de tablas usando la API web
Asociar y anular la asociación de filas de tabla mediante la API web
Uso de funciones de API web
Usar acciones de la API web
Ejecución de operaciones por lotes mediante la API web
Suplantar a otro usuario mediante la API web