Bien, entonces no se trata de idempotencia. Pero entonces una pregunta de seguimiento puede ser, ¿qué pasa si todavía elegimos usar 204 en la SUPRIMACIÓN posterior? ¿Está bien?
Buena pregunta. La motivación es comprensible: permitir que el cliente alcance el resultado deseado, sin preocuparse por el manejo de errores. Yo diría que devolver 204 en DELETE posterior, es una "mentira piadosa" del lado del servidor en gran parte inofensiva, que el lado del cliente no notará inmediatamente una diferencia. Es por eso que hay ~ 25% de personas haciendo eso en la naturaleza y aparentemente todavía funciona. Solo tenga en cuenta que dicha mentira puede considerarse semánticamente extraña, porque GET /non-exist
devuelve 404 pero DELETE /non-exist
da 204, en ese momento el cliente descubriría que su servicio no cumple completamente con la sección 6.5.4 404 No encontrado .
Pero quiero señalar que, la forma prevista por RFC 7231, es decir, devolver 404 en DELETE posterior, no debería ser un problema en primer lugar. Tres veces más desarrolladores decidieron hacer eso, ¿alguna vez escuchaste un incidente importante o una queja causada por un cliente que no puede manejar 404? Presumiblemente, no, y eso se debe a que cualquier cliente decente que implemente HTTP DELETE (o cualquier método HTTP, para el caso), no asumiría ciegamente que el resultado siempre sería exitoso 2xx. Y luego, una vez que el desarrollador comience a considerar el manejo de errores, 404 Not Found sería uno de los primeros errores que se le ocurra. En ese punto, él / ella probablemente sacaría una conclusión de que, es semánticamente seguro para una operación DELETE HTTP ignorar un error 404. Y lo hicieron así.