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.
- ¿Qué opina de mi pregunta de investigación de EE: ¿Hasta qué punto es WPA2 un medio viable de seguridad de red óptima para los consumidores?
- ¿Qué es el protocolo de datagramas de usuario?
- ¿Cuáles son los pros y los contras de MQTT versus MQTT-S como protocolos de red en IoT (Internet of Things)?
- ¿Por qué los protocolos de red ipv4 solo llegan a 255?
- ¿Cuál es la diferencia entre los números de secuencia de origen y destino en los protocolos de enrutamiento AODV?
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 🙂