Si una operación RESTful ‘PUT’ devuelve algo

Me preguntaba cuáles son las opiniones de las personas acerca de una operación RESTful PUT que no devuelve nada (nulo) en el cuerpo de la respuesta.

La especificación HTTP ( RFC 2616 ) tiene una serie de recomendaciones que son aplicables. Aquí está mi interpretación:

  • Código de estado HTTP 200 OK para un PUT exitoso de una actualización de un recurso existente. No se necesita un cuerpo de respuesta. (Según la Sección 9.6 , 204 No Content es aún más apropiado).
  • Código de estado HTTP 201 Created para un PUT exitoso de un nuevo recurso, con el URI más específico para el nuevo recurso devuelto en el campo de encabezado Ubicación y cualquier otro URI y metadatos relevantes del recurso repetidos en el cuerpo de la respuesta. ( RFC 2616 Sección 10.2.2 )
  • Código de estado HTTP 409 Conflict para un PUT que no es exitoso debido a una modificación de la parte, con una lista de diferencias entre la actualización intentada y el recurso actual en el cuerpo de la respuesta. ( RFC 2616 Sección 10.4.10 )
  • Código de estado HTTP 400 Bad Request de un PUT sin éxito, con texto en lenguaje natural (como inglés) en el cuerpo de respuesta que explica por qué falló el PUT. ( RFC 2616 Sección 10.4 )

A diferencia de la mayoría de las respuestas aquí, realmente creo que PUT debería devolver el recurso actualizado (además del código HTTP, por supuesto).

La razón por la que desea devolver el recurso como respuesta para la operación PUT es porque cuando envía una representación de recursos al servidor, el servidor también puede aplicar algún procesamiento a este recurso, por lo que el cliente desea saber cómo funciona este recurso. parecer después de que la solicitud se completó con éxito. (de lo contrario tendrá que emitir otra solicitud GET).

El código de respuesta Http de 201 para “Creado” junto con un encabezado “Ubicación” para indicar dónde el cliente puede encontrar el recurso recién creado.

La especificación HTTP / 1.1 (sección 9.6) discute los códigos de respuesta / error apropiados. Sin embargo, no aborda el contenido de la respuesta.

¿Qué esperarías? Un simple código de respuesta HTTP (200 etc.) me parece sencillo y claro.

Creo que es posible que el servidor devuelva contenido en respuesta a un PUT. Si está utilizando un formato de envolvente de respuesta que permite datos de carga lateral (como el formato consumido por datos de color), también puede incluir otros objetos que pueden haberse modificado mediante activadores de base de datos, etc. (Los datos de carga lateral se reducen explícitamente # de solicitudes, y este parece ser un buen lugar para optimizar.)

Si solo acepto el PUT y no tengo nada que informar, utilizo el código de estado 204 sin cuerpo. Si tengo algo que informar, utilizo el código de estado 200 e incluyo un cuerpo.

Usé RESTful API en mis servicios, y aquí está mi opinión: Primero debemos llegar a una vista común: PUT se usa para actualizar un recurso que no se crea ni se obtiene.

Definí los recursos con: Stateless resource y Stateful resource :

  • Recursos sin estado Para estos recursos, simplemente devuelva el HttpCode con el cuerpo vacío, es suficiente.

  • Recursos con estado Por ejemplo: la versión del recurso. Para este tipo de recursos, debe proporcionar la versión cuando desee cambiarla, así que devuelva el recurso completo o devuelva la versión al cliente, de modo que el cliente no necesite enviar una solicitud de obtención después de la acción de actualización.

Pero , para un servicio o sistema, mantenerlo simple , clearly , easy to use and maintain es lo más importante.

parece estar bien … aunque creo que una indicación rudimentaria de éxito / fracaso / tiempo publicado / # bytes recibidos / etc. sería preferible

editar: estaba pensando en la integridad de los datos y / o el mantenimiento de registros; Los metadatos como el hash MD5 o la marca de tiempo para el tiempo recibido pueden ser útiles para archivos de datos grandes.

Idealmente, devolvería una respuesta de éxito / fracaso.

Así como un cuerpo de Solicitud vacío está en consonancia con el propósito original de una solicitud GET y el cuerpo de respuesta vacío está en consonancia con el propósito original de una solicitud PUT.

Hay una diferencia entre el encabezado y el cuerpo de una respuesta HTTP. PUT nunca debe devolver un cuerpo, pero debe devolver un código de respuesta en el encabezado. Simplemente elija 200 si fue exitoso, y 4xx si no. No hay tal cosa como un código de retorno nulo. ¿Por qué quieres hacer esto?