Es un requisito bastante común para admitir recuperaciones o eliminaciones retrasadas / en lotes de servicios de datos. Lo que me pregunto es cómo implementar esto de una manera RESTANTE. Estoy dividido entre algunas opciones diferentes (ninguna de las cuales me parece terriblemente atractiva). Creo que es común en estas diferentes opciones la necesidad de una API que devuelva todos los recursos marcados como eliminados para un tipo de recurso en particular.

Aquí hay algunas opciones que he pensado y algunos de sus pros / contras:

Opciones para marcar el recurso como eliminado:

Utilice HTTP DELETE para marcar el recurso como eliminado.Utilice HTTP PUT / POST para actualizar la bandera eliminada. Esto no se siente bien ya que asigna lo que es esencialmente una eliminación del método DELETE HTTP y a otros métodos HTTP.

Opciones cuando GET-ing recurso marcado para eliminación:

Return HTTP Status 404 para un recurso marcado como eliminado. Limpio y transparente, pero ¿cómo distinguimos la diferencia entre un recurso que realmente se elimina frente a uno que se marca como eliminado?Return HTTP Status 410. Proporciona una forma de notar la diferencia, pero 410 técnicamente dice que "se espera que se considere permanente. Los clientes con capacidades de edición de enlaces DEBEN eliminar referencias al Request-URI después de la aprobación del usuario". Puede haber suficiente margen de maniobra en las palabras "esperado" y "DEBERÍA" aquí. No estoy seguro de qué tan bien se admite / entiende 410 en los clientes.Return HTTP Status 200 e incluye un campo de marca que indica que se ha eliminado el recurso. Esto parece extraño ya que la idea de eliminarlo en primer lugar fue porque realmente quería que no apareciera. Esto empuja la responsabilidad de filtrar los recursos eliminados a los clientes.

Opciones para respuestas que incluyen este recurso eliminado:

Omita los recursos marcados como eliminados. Limpio y simple. Pero, ¿qué pasa si realmente desea saber acerca de los recursos eliminados. Inclúyalos junto con el campo que indica que se eliminaron. Esto empuja la responsabilidad de filtrar los recursos eliminados a los clientes. Hace que la paginación sea complicada si solo desea navegar por los recursos activos o eliminados.

Opciones al actualizar un recurso marcado para su eliminación:

Utilice HTTP Status 404. El recurso se ha ido ¿verdad? Pero, ¿cómo puede saber la diferencia entre un recurso marcado como eliminado y uno realmente eliminado? El cuerpo HTTP en la respuesta 404 podría desambiguarse aquí, pero luego los clientes deben analizar / interpretar su cuerpo para desambiguar. ¿Quizás el encabezado de respuesta podría ayudar aquí? ¿Cúal? ¿Cabecera personalizadaUtilice HTTP Status 409 con un mensaje sobre cómo se debe recuperar el recurso primero.

Opciones para recuperar recursos marcados para eliminación:

Utilice HTTP PUT / POST para actualizar la operación del recurso y márquelo como activo nuevamente. Esto solo funciona siempre y cuando no devuelva un HTTP 404 para la operación GET para el recurso, ya que no realiza PUT / POST a un recurso que no se encuentra (404).Utilice HTTP PUT / POST para la operación de creación de recursos. El problema aquí es qué datos tienen prioridad? ¿Los datos enviados en la operación de creación? ¿O los datos que se están recuperando? filtrarlo de cualquier otra consulta que lo hubiera devuelto. Luego, trate el HTTP PUT / POST que crea el recurso como un undelete si el identificador del recurso apunta a un recurso marcado como eliminado.Separa la ruta REST dedicada a recuperar recursos marcados para su eliminación.

Esta de ninguna manera es una lista exhaustiva. Solo quería enumerar algunas de las opciones que han estado dando vueltas en mi cabeza.

Sé que la respuesta a cómo hacer esto es, como siempre, "depende". Lo que me interesa es qué calificaciones / requisitos usaría para tomar su decisión. ¿Cómo ha visto esto implementado o implementado usted mismo?