Te traemos la solución a esta aprieto, o por lo menos eso deseamos. Si presentas inquietudes dínoslo, que sin dudas
GET y POST son dos tipos diferentes de solicitudes HTTP.
Según Wikipedia:
OBTENER solicita una representación del recurso especificado. Tenga en cuenta que GET no debe usarse para operaciones que causen efectos secundarios, como usarlo para realizar acciones en aplicaciones web. Una razón para esto es que GET puede ser utilizado arbitrariamente por robots o rastreadores, que no deberían tener que considerar los efectos secundarios que debería causar una solicitud.
y
CORREO envía datos para ser procesados (por ejemplo, desde un formulario HTML) al recurso identificado. Los datos se incluyen en el cuerpo de la solicitud. Esto puede resultar en la creación de un nuevo recurso o la actualización de los recursos existentes o ambos.
Así que esencialmente GET se utiliza para recuperar datos remotos, y POST se utiliza para insertar/actualizar datos remotos.
Especificación HTTP/1.1 (RFC 2616) sección 9 Definiciones de métodos contiene más información sobre GET y POST así como los otros métodos HTTP, si está interesado.
Además de explicar los usos previstos de cada método, la especificación también proporciona al menos una razón práctica de por qué GET solo debe usarse para recuperar datos:
Los autores de servicios que utilizan el protocolo HTTP NO DEBEN utilizar formularios basados en GET para el envío de datos confidenciales, ya que esto hará que estos datos se codifiquen en la URI de solicitud. Muchos servidores, proxies y agentes de usuario existentes registrarán el URI de la solicitud en algún lugar donde pueda ser visible para terceros. Los servidores pueden usar el envío de formularios basados en POST en su lugar
Finalmente, una consideración importante al usar GET para solicitudes AJAX es que algunos navegadores, IE en particular, almacenarán en caché los resultados de un GET solicitud. Entonces, si usted, por ejemplo, realiza una encuesta usando el mismo GET request, siempre obtendrá los mismos resultados, incluso si los datos que está consultando se actualizan en el lado del servidor. Una forma de aliviar este problema es hacer que la URL sea única para cada solicitud agregando una marca de tiempo.
A POST, a diferencia de un GET, normalmente tiene información relevante en el cuerpo de la solicitud. (A GET no debe tener un cuerpo, así que aparte de las cookies, el único lugar para pasar información es en la URL). Además de mantener la URL relativamente más limpia, POST también le permite enviar mucha más información (ya que las URL tienen una longitud limitada, para todos los fines prácticos) y le permite enviar casi cualquier tipo de datos (los formularios de carga de archivos, por ejemplo, no pueden usar GET — tienen que usar POST más un tipo/codificación de contenido especial).
Aparte de eso, un POST connota que la solicitud cambiará algo, y no debe rehacerse a la ligera. Es por eso que a veces ve que su navegador le pregunta si desea volver a enviar los datos del formulario cuando presiona el botón “atrás”.
GET, por otro lado, debe ser idempotente — lo que significa que podría hacerlo un millón de veces y el servidor hará lo mismo (y mostrará básicamente el mismo resultado) todas y cada una de las veces.
Si bien no es una descripción de las diferencias, a continuación hay un par de cosas en las que pensar al elegir el método correcto.
- Las solicitudes GET pueden ser almacenadas en caché por el navegador, lo que puede ser un problema (o un beneficio) al usar ajax.
- Las solicitudes GET exponen los parámetros a los usuarios (POST también lo hace, pero son menos visibles).
- POST puede pasar mucha más información al servidor y puede tener casi cualquier longitud.
Te invitamos a auxiliar nuestro trabajo fijando un comentario o dejando una valoración te estamos eternamente agradecidos.