¿Por qué se usan HTTP Put y HTTP Delete cuando sus funciones también se pueden hacer con HTTP Post en el contexto de la arquitectura REST?

Bien por la misma lógica, ¿por qué usar POST cuando todo se puede lograr a través de GET? Tienes razón en que los diferentes verbos HTTP son prácticamente técnicamente equivalentes. Pueden codificar y enviar datos de manera diferente, pero no hay nada que pueda codificar en una solicitud POST que no pueda codificar en una solicitud GET.

(Refiriéndome aquí a los métodos generalmente asociados con REST: GET, POST, PATCH, PUT, DELETE. No estoy seguro de las diferencias técnicas de los otros verbos disponibles como CONNECT)

Realmente la pregunta es ¿por qué existen los verbos HTTP REST? La respuesta principal a esto es la estandarización. Al introducir un conjunto de verbos / métodos en la especificación HTTP, significa que cuando se utiliza una API que no diseñó, puede hacer llamadas y tener una expectativa de comportamiento. Si estos verbos no existieran, los diseñadores podrían haber inventado una solución loca para indicar una eliminación, creación o actualización.

También en el diseño de software existe el concepto de responsabilidad única. Si suponemos que no hay ningún método HTTP (o solo hay POST).

Entonces, ¿cómo indica qué quiere que haga su llamada a la API?

Póngalo en la URL.

.../post/242/delete

o ponerlo en el cuerpo (usando JSON como ejemplo)

{“action”: “delete”}

Pero ambos rompen el patrón de responsabilidad única. Se supone que la URL solo identifica el recurso en el que está operando. y el cuerpo de la solicitud solo debe contener datos nuevos que desee agregar / actualizar a la base de datos.

El uso de verbos también simplifica la API y evita el riesgo de errores ortográficos de los nombres de campo o URL para indicar diferentes acciones. ¡Y probablemente también hay un millón y una más de razones!

Espero que ayude 🙂

Puede lograr cualquier cosa solo con POST (por ejemplo, los servicios web SOAP solo usan POST). ¿Entonces por qué usar diferentes métodos HTTP?

  • Diferencia semántica: la intención de cada operación es diferente, por lo que ayuda a los desarrolladores a comprender la API. Además, ayuda a que la API sea consumible por la máquina, ya que un software puede comprender la semántica detrás de cada operación.
  • El método GET se puede almacenar en caché, mientras que otros no.
  • HTTP GET envía sus parámetros a través del URI, POST puede poner parámetros en su carga útil. Esto es importante para la seguridad.
  • Si tiene una colección de recursos /examples y desea crear un nuevo recurso, tiene sentido usar POST sobre ese URI. Ahora, si desea eliminar la colección /examples usando POST, es mucho más complicado considerando que ya está usando ese método sobre el mismo URI, que simplemente usando un método diferente (DELETE) sobre el mismo URI.

Por lo tanto, se trata de semántica, facilidad de uso y cómo se maneja cada método.

Como la mayoría de las áreas de CS y la vida en general, a los arquitectos les encanta complicar la vida de los constructores / desarrolladores para lograr sus hermosas arquitecturas de la misma funcionalidad.

En otras palabras, los verbos http adicionales no agregan nada. De hecho, podrían omitir el verbo por completo y hacer que el servidor funcione bien y enviar información útil.

También la sección de la cabeza y las URL complicadas, etc., son excesivas.

Simplemente no necesita tantas capas de abstracción en todo.

Son verbos que instruyen al servidor sobre sus intenciones. Para que pueda montar preocupaciones adicionales sobre: ​​piensa en la seguridad, por ejemplo.
HTTP se piensa de esa manera.
El valor agregado es que el mismo punto final puede reaccionar de manera diferente según el verbo actual. De esa manera, puede administrar el CRUD de un recurso con un único punto final.
No es una bala de plata, pero es mejor con que sin ella.