si utilizo el método PUT para la actualización, si también actualizo un atributo timestamp

Como LastUser y LastUpdate no son modificables por el cliente, los eliminaría de la representación de su recurso por completo. Permítanme explicar mi razonamiento con un ejemplo.

Digamos que nuestra API de ejemplo típica devolverá la siguiente representación al cliente cuando se le pida que proporcione un solo recurso:

GET /example/123

<?xml version="1.0" encoding="UTF-8" ?>
<example>
    <id>123</id>
    <lorem>ipsum</lorem>
    <dolor>sit amet</dolor>
    <lastUser uri="/user/321">321</lastUser>
    <lastUpdate>2011-04-16 20:00:00 GMT</lastUpdate>
</example>

Si un cliente quiere modificar el recurso, presumiblemente tomaría toda la representación y la enviaría de vuelta a la API.

PUT /example/123

<?xml version="1.0" encoding="UTF-8" ?>
<example>
    <id>123</id>
    <lorem>foobar</lorem>
    <dolor>foobaz</dolor>
    <lastUser>322</lastUser>
    <lastUpdate>2011-04-16 20:46:15 GMT+2</lastUpdate>
</example>

Dado que la API genera valores para lastUser y lastUpdate automáticamente y no puede aceptar datos proporcionados por el cliente, la respuesta más adecuada sería 400 Bad Request o 403 Forbidden (ya que el cliente no puede modificar estos valores).

Si queremos ser compatibles con REST y enviar una representación completa del recurso al hacer una solicitud PUT, necesitamos eliminar lastUser y lastUpdate de la representación del recurso. Esto permitirá a los clientes enviar la entidad completa a través de PUT:

PUT /example/123

<?xml version="1.0" encoding="UTF-8" ?>
<example>
    <id>123</id>
    <lorem>foobar</lorem>
    <dolor>foobaz</dolor>
</example>

El servidor aceptaría una representación completa ahora que no contiene lastUpdate y lastUser.

La pregunta que queda es cómo proporcionar a los clientes acceso a lastUpdate y lastUser. Si no lo necesitan (y estos campos son requeridos internamente por la API), estamos bien y nuestra solución es perfectamente RESTful. Sin embargo, si los clientes necesitan acceso a estos datos, el enfoque más limpio sería usar encabezados HTTP:

GET /example/123

...
Last-Modified: Sat, 16 Apr 2011 18:46:15 GMT
X-Last-User: /user/322
...

<?xml version="1.0" encoding="UTF-8" ?>
<example>
    <id>123</id>
    <lorem>foobar</lorem>
    <dolor>foobaz</dolor>
</example>

Usar un encabezado HTTP personalizado no es ideal porque los agentes de usuario necesitan que se les enseñe cómo leerlo. Si queremos proporcionar a los clientes acceso a los mismos datos de una manera más fácil, lo único que podemos hacer es poner los datos en la representación, y nos enfrentamos al mismo problema que en su pregunta original. Al menos intentaría mitigarlo de alguna manera. Si el tipo de contenido utilizado por la API es XML, podemos poner los datos en atributos de nodo en lugar de exponerlos directamente como valores de nodo, es decir:

GET /example/123

...
Last-Modified: Sat, 16 Apr 2011 18:46:15 GMT
...

<?xml version="1.0" encoding="UTF-8" ?>
<example last-update="2011-04-16 18:46:15 GMT" last-user="/user/322">
    <id>123</id>
    <lorem>foobar</lorem>
    <dolor>foobaz</dolor>
</example>

De esta manera al menos evitaremos el problema en el que un cliente intentaría enviar todos los nodos XML en una solicitud PUT de seguimiento. Esto no funcionará con JSON, y la solución todavía está un poco al borde de idempotency (ya que la API todavía tendría que ignorar los atributos XML al procesar la solicitud).

Aún mejor, como Jonah señaló en los comentarios, si los clientes necesitan acceso a lastUser y lastUpdate, estos pueden exponerse como un nuevo recurso, vinculado desde el original, por ejemplo, como sigue:

GET /example/123

<?xml version="1.0" encoding="UTF-8" ?>
<example>
    <id>123</id>
    <lorem>foobar</lorem>
    <dolor>foobaz</dolor>
    <lastUpdateUri>/example/123/last-update</lastUpdateUri>
</example>

... y entonces:

GET /example/123/last-update

<?xml version="1.0" encoding="UTF-8" ?>
<lastUpdate>
    <resourceUri>/example/123</resourceUri>
    <updatedBy uri="/user/321">321</updatedBy>
    <updatedAt>2011-04-16 20:00:00 GMT</updatedAt>
</lastUpdate>

(Lo anterior también se puede ampliar para proporcionar un registro de auditoría completo con cambios individuales, siempre que esté disponible un registro de cambios de recursos.)

Tenga en cuenta:
Estoy de acuerdo con Darrel Miller 's asumir la pregunta , pero yo quería proporcionar un enfoque diferente en la parte superior de la misma. Tenga en cuenta que este enfoque no está respaldado por ningún estándar/RFC/etc, es solo una versión diferente de la problema.

La desventaja de usar PUT para crear recursos es que el cliente tiene que proporcionar el ID único que representa el objeto que está creando. Si bien generalmente es posible que el cliente genere este ID único, la mayoría de los diseñadores de aplicaciones prefieren que sus servidores (generalmente a través de sus bases de datos) creen este ID. En la mayoría de los casos queremos que nuestro servidor controle la generación de ID de recursos. Entonces, ¿qué hacemos? Podemos cambiar a usar POST en lugar de PUT.

Así que:

Poner = UPDATE

Post = INSERTAR

Con suerte, esto ayuda para su caso específico.

Los métodos HTTP POST y PUT no son el equivalente HTTP de create y update de CRUD. Ambos tienen un propósito diferente. Es muy posible, válido e incluso preferido en algunas ocasiones, usar PUT para crear recursos, o usar POST para actualizar recursos.

Use PUT cuando puede actualizar un recurso completamente a través de un recurso específico. Por ejemplo, si sabe que un artículo reside en http://example.org/article/1234 , puede PONER una nueva representación de recursos de este artículo directamente a través de un PUESTO en esta URL.

Si no conoce la ubicación real del recurso, por ejemplo, cuando agrega un nuevo artículo, pero no tiene idea de dónde almacenarlo, puede publicarlo en una URL y dejar que el servidor decida la URL real.