La guía paso a paso o código que hallarás en este artículo es la resolución más rápida y válida que hallamos a tu duda o problema.
Solución:
La ventaja es principalmente semántica y también puede simplificar las URL hasta cierto punto. Los diferentes métodos HTTP se asignan a diferentes acciones:
POST => create a new object
DELETE => delete an object
PUT => modify an object
GET => view an object
Entonces, en teoría, puede utilizar el mismo URL, pero interactuar con ella utilizando diferentes métodos; el método utilizado para acceder al recurso define el tipo real de operación.
Sin embargo, en la práctica, la mayoría de los navegadores solo admiten HTTP GET y POST. Rails utiliza algunos “trucos” en los formularios HTML para actuar como si se enviara una solicitud PUT o DELETE, aunque Rails todavía usa GET o POST para estos métodos. (Esto explica por qué es posible que no haya utilizado DELETE o PUT en otras plataformas).
Aquí está la sección “métodos” de la especificación HTTP 1.1; define muchos métodos, y todos tienen diferentes beneficios y compensaciones. POST es el más flexible, pero las compensaciones son numerosas: no se puede almacenar en caché (por lo que el resto de Internet no puede ayudarlo a escalar), no es seguro ni idempotente, por lo que el cliente no puede simplemente reenviarlo obtiene un error, y ya no está claro exactamente lo que está tratando de lograr (porque es muy flexible). Estoy seguro de que hay otros, pero eso debería ser suficiente. Dado todo eso, si la especificación HTTP define un método que hace exactamente lo que desea que haga su solicitud, no hay razón para enviar un POST en lugar de.
La razón POST es tan común es que, históricamente al menos, los navegadores web solo son compatibles GET y POST. Ya que GET se define como seguro e idempotente (aunque muchas aplicaciones no se adhieren a eso), el único a salvo forma de modificar los datos era enviar un POST. Con el aumento de AJAX y clientes que no son navegadores, eso ya no es true.
Por cierto, el mapeo que dio @mipadi es el mapeo estándar, pero no es el único válido. Amazon S3, por ejemplo, usa PUT para crear recursos. La única razón para usar POST es si el cliente no tiene el conocimiento suficiente para crear el recurso, por ejemplo, respalda sus recursos con una base de datos relacional y usa un sustituto artificial keys.
Eso sería algo así como preguntar por qué “eliminar” un archivo cuando podría establecer su contenido en cero bytes y el sistema de archivos lo trataría como una eliminación. HTTP ha admitido verbos distintos de GET / POST para siempre, pero la forma en que SOAP evolucionó torció un poco el significado original de esos verbos. REST es un enfoque más simple, de regreso a lo básico, que usa los verbos como se pretendía en lugar de inventar un nuevo concepto de verbo dentro de la carga útil.