Método PUT (marco de trabajo de los servicios de datos de ADO.NET)

Los protocolos para el uso del método PUT por parte de los servicios de datos de ADO.NET se describen en las siguientes listas y ejemplos. Otro comportamiento requerido por el Hypertext Transfer Protocol, RFC 2616 se describe en Requisitos HTTP comunes (marco de trabajo de los servicios de datos de ADO.NET) y PUT, POST y DELETE (marco de trabajo de servicios de datos de ADO.NET).

Los siguientes protocolos se aplican a las solicitudes HTTP que usan el método PUT.

• Todas las solicitudes PUT correctas devuelven un código de respuesta 204 Sin contenido.

• Una solicitud PUT de un recurso de los servicios de datos de ADO.NET combina el contenido de la solicitud con el estado actual del recurso. La combinación se realiza mediante la comparación de cada componente del cuerpo de la solicitud con el recurso tal y como está en el servidor.

  • Si hay un componente en el cuerpo de la solicitud que no esté en el recurso, la solicitud representa una infracción de esquema y se devolverá un código de respuesta 422 Entidad no procesable.

  • Cuando un componente del cuerpo de la solicitud coincida con un componente del recurso, continúa el proceso de coincidencia con los elementos secundarios del elemento del cuerpo de la solicitud.

• Una solicitud PUT para establecer el valor de un recurso en NULL cuando el tipo del recurso no acepte valores NULL tiene como resultado un código de respuesta 422 Entidad no procesable.

• Una solicitud PUT para establecer el valor de un recurso en vacío cuando el tipo del recurso no defina ningún estado vacío tiene como resultado un código de respuesta 422 Entidad no procesable.

• Puesto que PUT debe tener el valor idempotent, no puede usar PUT para insertar recursos en un conjunto de recursos. Es decir, PUT no puede implementar anexiones tipo POST ni crear semántica.

• Se omiten las anotaciones de contenido aplazado en la carga de solicitud.

• Si el URI de solicitud del encabezado HTTP no coincide con el URI asociado de la carga de solicitud, el URI de solicitud tiene prioridad. La carga se trata como si incluyese el valor del URI de solicitud.

• Si el cuerpo de la solicitud PUT contiene las claves de los recursos en los que se están realizando operaciones como parte de la serialización de un recurso, se omiten estos valores de clave. Los valores de clave de los recursos no se pueden actualizar.

Tipos que admiten el método PUT

Los ejemplos que se encuentran más adelante en este documento resumen los tipos de recursos que admiten el método PUT. Una solicitud PUT de un tipo de recurso que admita el método PUT puede provocar un error si los derechos del principio solicitante no son suficientes en el recurso especificado. En este caso, como se describe en el Hypertext Transfer Protocol, RFC 2616, la solicitud devuelve un código de respuesta 401 No autorizado o un código de respuesta 403 Prohibido, en función de si al proporcionar un principio alternativo en el servicio de datos se podría permitir la correcta ejecución de la solicitud.

Los siguientes ejemplos muestran los elementos finales de la sintaxis de la dirección URL de HTTP que admiten o no el método PUT. Cada caso incluye una descripción de una solicitud PUT y los resultados predecibles.

/<EntitySet>

Ejemplo de elemento final del URI

El siguiente ejemplo de URI muestra un conjunto de entidades como elemento final.

/Customers

Descripción:

El método PUT no es compatible con un conjunto de entidades como elemento final. Se devuelve un código de respuesta 405 Método no admitido.

/<EntitySet>(keyPredicate)

El siguiente ejemplo de URI muestra un elemento keyPredicate como elemento final.

/Customers('ALFKI') 

Descripción:

• Admite el método PUT.

• Actualiza la instancia de tipo de recurso único proporcionado por el cuerpo de la solicitud e identificado por keyPredicate

  • No se admiten actualizaciones profundas en tipos asociados.

  • Admite el enlace de la parte de una relación que tiene una cardinalidad de uno.

• Habilita el enlace del recurso R1 identificado por keyPredicate en los recursos existentes:

  • Si R1 contiene sólo el URI de un recurso existente R2 como el valor de una navegación o de un vínculo que identifica la parte de una relación que tiene una cardinalidad de uno, R1 se enlaza a R2.

  • Si R1 contiene el URI y el cuerpo del recurso, se asume que el URI representa un recurso existente R2 que ya está enlazado a R1. Después, R2 se actualiza con los valores especificados en el cuerpo.

  • Si R1 contiene sólo el cuerpo pero no el URI de un recurso R2 relacionado como el valor de una propiedad de navegación o de vínculo, se devuelve 400 Solicitud incorrecta.

• Si se envía una carga igual que el valor literal de NULL a este recurso, se obtiene un código de respuesta 400 Solicitud incorrecta.

• El valor de la propiedad o propiedades que forman la clave del recurso no se pueden actualizar. Si se presentan los nuevos valores de la carga de una solicitud PUT, se omiten.

El siguiente ejemplo de URI muestra un predicado de clave numérica como elemento final. El código actualiza el Producto Nº 123 y la categoría al que está asociado; reenlaza la categoría asociada.

/Products(123)

Formato JSON

{
__metadata:{ uri="/Products(123)", 
type="NorthwindModel.Product" },
Name:"New product name"
Category :   { __metadata: {uri:"/Category(2)" } }
}

/<NavigationProperty> o /<LinkProperty>

Los siguientes ejemplos de URI muestran las propiedades de navegación y de vínculo como elementos finales.

/Customers('ALFKI')/Orders

/Customers('ALKFI')/Orders(1)

/Products(1)/Category (sólo funciona en los extremos de relaciones con una cardinalidad = 1)

Descripción:

• Admite el método PUT.

• Si la propiedad de navegación o de vínculo identifica un único recurso o el extremo de una relación con una cardinalidad de uno:

  • Usa la misma semántica que /<ResourceSet>(keyPredicate) salvo que el cuerpo de una solicitud contiene sólo el valor NULL que desenlaza el recurso del recurso que identifica el segmento del antepenúltimo URI.

• Si la propiedad de navegación o de vínculo identifica varios recursos o el extremo "muchas" de una relación:

  • No admitido, se devuelve un código de respuesta 405 Método no admitido.

/<ComplexType>

El siguiente ejemplo de URI muestra un tipo complejo como elemento final.

/Customers('ALFKI')/Address

Descripción:

• Admite el método PUT.

• Actualiza el tipo complejo identificado por la hoja del URI de solicitud con el contenido del cuerpo de la solicitud.

• Admite actualizaciones profundas.

• La carga de la solicitud quizá incluya contenido de tipos complejos anidados que se pueda actualizar. No existe una profundidad máxima definida para tales actualizaciones en tanto que la profundidad se mantenga en la instancia del tipo de recurso contenedor.

/<Property>

El siguiente ejemplo de URI muestra una propiedad como elemento final:

/Customers('ALFKI')/FirstName

Descripción:

• Admite el método PUT.

• Admite la actualización del valor de la propiedad.

• La propiedad se puede establecer en NULL.

  • JSON utiliza el primitivo NULL.

/<Property>/$value

El siguiente ejemplo de URI muestra el valor de una propiedad como elemento final:

/Customers('ALFKI')/FirstName/$value

Descripción:

• Admite el método PUT.

• Admite la actualización del valor sin formato de la propiedad.

• No proporciona ninguna forma de establecer el valor en NULL.

• El tipo MIME del cuerpo de la solicitud debe coincidir con el del tipo de recurso del servidor.

• Una solicitud de cero bytes establece el valor de la propiedad en vacío si el tipo de la propiedad define un estado vacío; de lo contrario, se devuelve un código de respuesta 422 Entidad no procesable.

/<ServiceOperationName>

El siguiente ejemplo de URI muestra el nombre de una operación de servicio como elemento final:

/CustomersByCity?city='London'

Descripción:

• No admite el método PUT.

• El verbo PUT no se define para las operaciones de los servicios de datos de ADO.NET.

• Devuelve el código de respuesta 405 Método no admitido.

Limitación de ida y vuelta de la solicitud PUT

El marco de trabajo de los servicios de datos de ADO.NET admite un escenario de ida y vuelta que use una solicitud GET en un URI concreto para devolver una carga. Un escenario típico sería modificar parte de los datos y pasar la misma carga a una solicitud PUT de ese URI. Este proceso no funcionará si una propiedad de una entidad no es una clave sino una columna de identidad. La única solución es cambiar la columna de identidad del archivo de lenguaje de definición de esquemas de almacén (SSDL) a una propiedad calculada.

Vea también

Conceptos

HttpWebRequest GET (marco de trabajo de los servicios de datos de ADO.NET)
HttpWebRequest PUT (marco de trabajo de los servicios de datos de ADO.NET)
HttpWebRequest POST (marco de trabajo de los servicios de datos de ADO.NET)
HttpWebRequest DELETE (marco de trabajo de los servicios de datos de ADO.NET)
PUT, POST y DELETE (marco de trabajo de servicios de datos de ADO.NET)