Permití un reemplazo total de una colección, por ejemplo, PUT ~/people/123/shoes
donde el cuerpo es la representación de la colección completa.
Esto funciona para colecciones de elementos de niños pequeños en las que el cliente quiere revisar los elementos y eliminar algunos y agregar otros y luego actualizar el servidor. Podrían PONER una colección vacía para borrar todo.
Esto significaría GET ~/people/123/shoes/9
que aún permanecería en el caché a pesar de que un PUT lo eliminó, pero eso es solo un problema de almacenamiento en caché y sería un problema si otra persona eliminara el zapato.
Mis API de datos / sistemas siempre usan ETag en lugar de tiempos de caducidad, por lo que el servidor recibe cada solicitud y necesito encabezados de versión / concurrencia correctos para mutar los datos. Para las API que son de solo lectura y alineadas con vistas / informes, utilizo tiempos de vencimiento para reducir las visitas al origen, por ejemplo, una tabla de clasificación puede ser válida durante 10 minutos.
Para colecciones mucho más grandes, por ejemplo ~/people
, no suelo necesitar una eliminación múltiple, el caso de uso tiende a no surgir de forma natural y, por lo tanto, un DELETE único funciona bien.
En el futuro, y de la experiencia con la creación de API REST y con los mismos problemas y requisitos, como auditoría, me inclinaría a usar solo verbos GET y POST y diseñar en torno a eventos, por ejemplo, POST un evento de cambio de dirección, aunque sospecho que vendrá con su propio conjunto de problemas :)
También permitiría a los desarrolladores de front-end crear sus propias API que consuman API de back-end más estrictas, ya que a menudo existen razones prácticas y válidas del lado del cliente por las que no les gustan los diseños de API REST estrictos "Fielding fanáticos", y para la productividad y razones de capas de caché.