tutorial - RESTful: ¿Qué debe contener un cuerpo de respuesta DELETE?

rest php

Question

Digamos que tengo una API donde puedes obtener usuarios:

GET /RESTAPI/user/

Y puedes eliminar usuarios por:

DELETE /RESTAPI/user/123

¿Cuál es la convención RESTful sobre lo que debe contener el cuerpo de respuesta de DELETE? Esperaba que fuera la nueva lista de todos los usuarios que ahora ya no contiene al usuario con id 123.

Buscar en Google no me dio ninguna respuesta satisfactoria. Solo encontré opiniones sobre cómo hacer eso, pero ¿no hay una definición estricta de Servicios REST ?

Esto NO es un duplicado de ¿Qué debe devolver un POST / DELETE API RESTful en el cuerpo? y ¿Qué llamadas REST PUT / POST / DELETE deben devolverse por una convención? ya que esta pregunta pide una definición estricta con respecto a BORRAR. Esas preguntas fueron contestadas solamente por opiniones sueltas solamente.

Answer 1

¿Cuál es la convención RESTful sobre lo que debe contener el cuerpo de respuesta de DELETE ?

REST es un estilo arquitectónico definido por Fielding en el capítulo 5 de su disertación y describe un conjunto de reglas para aplicaciones construidas con esta arquitectura. REST está diseñado para ser independiente del protocolo, pero el capítulo 6 de la misma disertación describe cómo se aplica REST sobre HTTP.

Una vez que su aplicación REST esté diseñada en la parte superior del protocolo HTTP, debe conocer la semántica de HTTP. Y la semántica del protocolo HTTP / 1.1 se describe actualmente en el RFC 7231 .

La carga útil de respuesta de una solicitud DELETE que ha tenido éxito puede:

• Estar vacío o
• Incluir una representación del estado de la acción.

Y los siguientes códigos de estado de respuesta son adecuados para una solicitud DELETE que ha tenido éxito:

• 202 : La solicitud ha sido aceptada para su procesamiento, pero el procesamiento no se ha completado.
• 204 : El servidor ha cumplido satisfactoriamente con la solicitud y no hay contenido adicional para enviar en el cuerpo de la carga útil de respuesta.
• 200 : La solicitud ha tenido éxito y la carga útil de la solicitud incluye una representación del estado de la acción.

Vea la siguiente cita del RFC 7231 :

Si se aplica con éxito un método DELETE , el servidor de origen DEBERÍA enviar un código de estado 202 (aceptado) si la acción probablemente tendrá éxito pero aún no se ha promulgado, un código de estado 204 (Sin contenido) si la acción se ha promulgado y no más. se debe proporcionar información o un código de estado 200 (OK) si la acción se ha promulgado y el mensaje de respuesta incluye una representación que describe el estado.

Answer 2

La razón por la que no obtiene respuestas difíciles es porque no hay un estándar REST. Por lo tanto, solo puedo sugerirle que cree un estándar estricto y se adhiera a él dentro de sus propias API.

Usé esto como una guía para los servicios RESTful http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

Dice responder con un estado 204 y un cuerpo vacío.

Me atengo a esos estándares y los documento bien para cualquier persona que quiera usar mis API

Answer 3

Yo diría que lo mejor es mantener las respuestas uniformes independientemente de la llamada. Diciendo esto desde un punto de vista más pragmático ya que trabajo con muchas API. Realmente no me gusta tratar con diferentes encabezados, códigos de estado, etc. por respuesta. La respuesta 200 es la mejor, y el cuerpo podría tener algo sobre la respuesta. No es obvio que una solicitud DELETE, por ejemplo, haya eliminado realmente algo. Una respuesta podría indicar eso o si hubo un error.

Answer 4

204 No Content es una respuesta popular para DELETE y ocasionalmente también PUT .

Sin embargo, si está implementando HATEOAS, devolver un 200 OK con enlaces a seguir puede ser más ideal. Esto se debe a que una API REST de HATEOAS proporciona un contexto para el cliente. Piense en la ubicación a la que navega una aplicación de usuario después de emitir con éxito un comando de eliminación. Aquí hay un breve extracto del artículo con más discusión sobre esto. Vea el artículo del blog para una discusión más completa.

• Artículo: http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

Evita 204 respuestas si estás creando una aplicación HATEOAS.

Esta es una lección sobre el diseño de la API REST que aprendí al crear API REST no triviales. Para que el cliente sea tan solidario como sea posible, una API REST no debe devolver 204 respuestas (sin contenido).

Desde la perspectiva del servicio, una respuesta 204 (Sin contenido) puede ser una respuesta perfectamente válida a una solicitud POST, PUT o DELETE. Particularmente, para una solicitud de BORRAR parece muy apropiado, porque ¿qué más se puede decir?

Sin embargo, desde la perspectiva de un cliente adecuado para HATEOAS, una respuesta 204 es problemática porque no hay enlaces a seguir. Cuando la hipermedia actúa como el motor del estado de la aplicación, cuando no hay enlaces, no hay estado. En otras palabras, una respuesta 204 elimina todo el estado de la aplicación.

Este artículo cubre POST , PUT , DELETE y GET . Aquí está la discusión específica en DELETE :

Respondiendo a las solicitudes DELETE

Una solicitud DELETE representa la intención de eliminar un recurso. Por lo tanto, si el servicio maneja con éxito una solicitud DELETE, ¿qué más puede hacer que devolver un 204 (Sin contenido)? Después de todo, el recurso acaba de ser eliminado.

Un recurso es a menudo un miembro de una colección, o “propiedad” de un contenedor. Como ejemplo, http://foo.ploeh.dk/api/tags/rock representa una etiqueta "rock", pero otra forma de verlo es que el recurso / rock está contenido dentro del contenedor de etiquetas (que en sí mismo es un recurso). Esto debería ser familiar para los usuarios de Atom Pub.

Imagina que quieres eliminar el recurso http://foo.ploeh.dk/api/tags/rock . Para lograr ese objetivo, emite una solicitud DELETE en su contra. Si todo lo que su cliente recibe es un 204 (Sin contenido), simplemente pierde su contexto. ¿A dónde va desde allí? A menos que mantengas el estado en el cliente, no sabes de dónde vienes.

En lugar de devolver 204 (Sin contenido), la API debería ser útil y sugerir lugares a donde ir. En este ejemplo, creo que un enlace obvio para proporcionar es http://foo.ploeh.dk/api/tags : el contenedor del cual el cliente acaba de eliminar un recurso. Tal vez el cliente desee eliminar más recursos, por lo que sería un enlace útil.