De lo que puedo reunir, hay tres categorías:

1. Nunca use GETy usePOST
2. Nunca use POSTy useGET
3. No importa cuál uses.

¿Estoy en lo cierto al asumir esos tres casos? Si es así, ¿cuáles son algunos ejemplos de cada caso?

Úselo POSTpara acciones destructivas como la creación (soy consciente de la ironía), la edición y la eliminación, porque no puede presionar una POSTacción en la barra de direcciones de su navegador. Úselo GETcuando sea seguro permitir que una persona llame a una acción. Entonces una URL como:

http://myblog.org/admin/posts/delete/357

Debería llevarlo a una página de confirmación, en lugar de simplemente eliminar el elemento. Es mucho más fácil evitar accidentes de esta manera.

POSTtambién es más seguro que GET, porque no está pegando información en una URL. Y, por lo tanto, utilizar GETcomo methodun formulario HTML que recopila una contraseña u otra información confidencial no es la mejor idea.

Una nota final: POSTpuede transmitir una mayor cantidad de información que GET. 'POST' no tiene restricciones de tamaño para los datos transmitidos, mientras que 'GET' está limitado a 2048 caracteres.

En breve

• Uso GETpara safe andidempotentsolicitudes
• Uso POSTpara neither safe nor idempotentsolicitudes

En detalles Hay un lugar adecuado para cada uno. Incluso si no sigue los principios RESTful , se puede ganar mucho al aprender sobre REST y cómo funciona un enfoque orientado a los recursos.

Una aplicación RESTful lo hará use GETspara operaciones que son ambas safe and idempotent.

Una safeoperación es una operación que se not change the datasolicita.

Una idempotentoperación es aquella en la que el resultado be the sameno importa cuántas veces lo solicite.

Es lógico pensar que, dado que los GET se utilizan para operaciones seguras , también son automáticamente idempotentes . Normalmente, un GET se usa para recuperar un recurso (una pregunta y sus respuestas asociadas en el desbordamiento de la pila, por ejemplo) o una colección de recursos.

Se usará una aplicación RESTful PUTspara operaciones que son not safe but idempotent.

Sé que la pregunta era sobre GET y POST, pero volveré a POST en un segundo.

Normalmente, se utiliza un PUT para editar un recurso (por ejemplo, editar una pregunta o una respuesta en el desbordamiento de la pila).

A POSTse usaría para cualquier operación que sea neither safe or idempotent.

Normalmente, una POST se usaría para crear un nuevo recurso, por ejemplo, crear una NUEVA pregunta SO (aunque en algunos diseños también se usaría un PUT para esto).

Si ejecuta la POST dos veces, terminaría creando DOS nuevas preguntas.

También hay una operación DELETE, pero supongo que puedo dejar eso allí :)

Discusión

En términos prácticos, los navegadores web modernos generalmente solo admiten GET y POST de manera confiable (puede realizar todas estas operaciones a través de llamadas javascript, pero en términos de ingresar datos en formularios y presionar enviar, generalmente tiene las dos opciones). En una aplicación RESTful, la POST a menudo se anulará para proporcionar también las llamadas PUT y DELETE.

Pero, incluso si no sigue los principios RESTful, puede ser útil pensar en términos de uso de GET para recuperar / ver información y POST para crear / editar información.

Nunca debe usar GET para una operación que altera los datos. Si un motor de búsqueda rastrea un enlace a su operación malvada, o los marcadores del cliente, podría significar grandes problemas.

Use GET si no le importa que se repita la solicitud (es decir, no cambia de estado).

Use POST si la operación cambia el estado del sistema.

Version corta

OBTENER: Usualmente se usa para solicitudes de búsqueda enviadas, o cualquier solicitud en la que desea que el usuario pueda volver a abrir la página exacta.

Ventajas de GET:

• Las URL se pueden marcar de forma segura.
• Las páginas se pueden recargar de forma segura.

Desventajas de GET:

• Las variables se pasan a través de url como pares de nombre-valor. (Riesgo de seguridad)
• Número limitado de variables que se pueden pasar. (Basado en el navegador. Por ejemplo, Internet Explorer está limitado a 2.048 caracteres ) .

POST: se utiliza para solicitudes de mayor seguridad donde los datos se pueden usar para alterar una base de datos o una página que no desea que alguien marque.

Ventajas de POST:

• Los pares de nombre-valor no se muestran en la URL. (Seguridad + = 1)
• Se puede pasar un número ilimitado de pares de nombre-valor a través de POST. Referencia.

Desventajas de POST:

• La página que utilizó datos POST no puede ser marcada. (Si así lo deseas)

Versión más larga

Directamente desde el Protocolo de transferencia de hipertexto - HTTP / 1.1 :

9.3 OBTENER

El método GET significa recuperar cualquier información (en forma de entidad) identificada por el URI de solicitud. Si el URI de solicitud se refiere a un proceso de producción de datos, son los datos producidos los que se devolverán como la entidad en la respuesta y no el texto fuente del proceso, a menos que ese texto sea el resultado del proceso.

La semántica del método GET cambia a un "GET condicional" si el mensaje de solicitud incluye un campo de encabezado If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match o If-Range. Un método GET condicional solicita que la entidad se transfiera solo en las circunstancias descritas por los campos de encabezado condicional. El método GET condicional está destinado a reducir el uso innecesario de la red al permitir que las entidades en caché se actualicen sin requerir múltiples solicitudes o transferir datos que ya tiene el cliente.

La semántica del método GET cambia a "GET parcial" si el mensaje de solicitud incluye un campo de encabezado Range. Un GET parcial solicita que solo se transfiera parte de la entidad, como se describe en la sección 14.35. El método GET parcial está destinado a reducir el uso innecesario de la red al permitir que se completen entidades parcialmente recuperadas sin transferir los datos que ya tiene el cliente.

La respuesta a una solicitud GET se puede almacenar en caché si y solo si cumple con los requisitos de almacenamiento en caché HTTP descritos en la sección 13.

Consulte la sección 15.1.3 para ver las consideraciones de seguridad cuando se utiliza para formularios.

9.5 POST

El método POST se utiliza para solicitar que el servidor de origen acepte la entidad incluida en la solicitud como un nuevo subordinado del recurso identificado por el URI de solicitud en la línea de solicitud. POST está diseñado para permitir un método uniforme para cubrir las siguientes funciones:

• Anotación de recursos existentes;

• Publicar un mensaje en un tablón de anuncios, grupo de noticias, lista de correo o grupo similar de artículos;

• Proporcionar un bloque de datos, como el resultado de enviar un formulario, a un proceso de manejo de datos;

• Extender una base de datos a través de una operación de agregar.

La función real realizada por el método POST la determina el servidor y, por lo general, depende del URI de solicitud. La entidad publicada está subordinada a ese URI de la misma manera que un archivo está subordinado a un directorio que lo contiene, un artículo de noticias está subordinado a un grupo de noticias en el que está publicado o un registro está subordinado a una base de datos.

La acción realizada por el método POST podría no dar como resultado un recurso que pueda ser identificado por un URI. En este caso, 200 (OK) o 204 (Sin contenido) es el estado de respuesta apropiado, dependiendo de si la respuesta incluye o no una entidad que describa el resultado.

Lo primero importante es el significado de GET versus POST:

• GET debería usarse para ... obtener ... alguna información del servidor,
• mientras que POST debe usarse para enviar alguna información al servidor.

Después de eso, hay un par de cosas que se pueden notar:

• Con GET, los usuarios pueden usar el botón "Atrás" en su navegador y pueden marcar páginas
• Hay un límite en el tamaño de los parámetros que puede pasar como GET (2 KB para algunas versiones de Internet Explorer, si no me equivoco) ; el límite es mucho más para POST, y generalmente depende de la configuración del servidor.

De todos modos, no creo que podamos "vivir" sin GET: piense en cuántas URL está utilizando con parámetros en la cadena de consulta, todos los días, sin GET, todo eso no funcionaría ;-)

Además de la diferencia de restricciones de longitud en muchos navegadores web, también existe una diferencia semántica. Se supone que los GET son "seguros" porque son operaciones de solo lectura que no cambian el estado del servidor. Los POST generalmente cambiarán de estado y darán advertencias en el reenvío. Los rastreadores web de los motores de búsqueda pueden hacer GET pero nunca deben hacer POST.

Use GET si desea leer datos sin cambiar el estado, y use POST si desea actualizar el estado en el servidor.

Mi regla general es usar Get cuando realiza solicitudes al servidor que no van a alterar el estado. Las publicaciones están reservadas para solicitudes al servidor que alteran el estado.

Una diferencia práctica es que los navegadores y los servidores web tienen un límite en la cantidad de caracteres que pueden existir en una URL. Es diferente de una aplicación a otra, pero sin duda es posible acertar si tienes textareas en tus formularios.

Otro problema con los GET: los motores de búsqueda y otros sistemas automáticos los indexan. Google una vez tuvo un producto que buscaba previamente enlaces en la página que estaba viendo, por lo que sería más rápido cargarlos si hace clic en esos enlaces. Causó grandes estragos en los sitios que tenían enlaces como delete.php?id=1: las personas perdieron sus sitios completos.

Use GET cuando desee que la URL refleje el estado de la página. Esto es útil para ver páginas generadas dinámicamente, como las que se ven aquí. Se debe usar una POST en un formulario para enviar datos, como cuando hago clic en el botón "Publicar su respuesta". También produce una URL más limpia, ya que no genera una cadena de parámetros después de la ruta.

Debido a que los GET son puramente URL, pueden ser almacenados en caché por el navegador web y pueden usarse mejor para cosas como imágenes generadas consistentemente. (Establecer un tiempo de caducidad)

Un ejemplo de la página gravatar: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

GET puede ofrecer un rendimiento marginalmente mejor, algunos servidores web escriben contenidos POST en un archivo temporal antes de invocar el controlador.

Otra cosa a considerar es el límite de tamaño. Los GET están limitados por el tamaño de la URL, 1024 bytes por el estándar, aunque los navegadores pueden admitir más.

La transferencia de más datos que eso debería usar una POST para obtener una mejor compatibilidad del navegador.

Incluso menos de ese límite es un problema, como escribió otro póster, cualquier cosa en la URL podría terminar en otras partes de la interfaz de usuario del navegador, como el historial.

No hay nada que no puedas hacer per se. El punto es que se supone que no debes modificar el estado del servidor en un HTTP GET. Los proxys HTTP suponen que dado que HTTP GET no modifica el estado, entonces si un usuario invoca HTTP GET una vez o 1000 veces no hace ninguna diferencia. Con esta información, suponen que es seguro devolver una versión en caché del primer HTTP GET. Si rompe la especificación HTTP, corre el riesgo de romper el cliente HTTP y los servidores proxy en la naturaleza. No lo hagas :)

Esto atraviesa el concepto de REST y cómo la web estaba destinada a ser utilizada. Hay un excelente podcast en la radio de Ingeniería de Software que ofrece una charla en profundidad sobre el uso de Get and Post.

Get se usa para extraer datos del servidor, donde no se necesita una acción de actualización. La idea es que debería poder usar la misma solicitud GET una y otra vez y que se le devuelva la misma información. La URL tiene la información de obtención en la cadena de consulta, porque estaba destinada a poder enviarse fácilmente a otros sistemas y a las personas les gusta una dirección sobre dónde encontrar algo.

Se supone que Post debe ser utilizado (al menos por la arquitectura REST en la que se basa la web) para enviar información al servidor / decirle al servidor que realice una acción. Ejemplos como: Actualizar estos datos, Crear este registro.

1.3 Lista de verificación rápida para elegir HTTP GEToPOST

Use GET si:

    The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

Use POST si:

    The interaction is more like an order, or
    The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    The user be held accountable for the results of the interaction.

Fuente .

Sin embargo, no veo un problema con get, lo uso para cosas simples en las que tiene sentido mantener las cosas en la cadena de consulta.

Usarlo para actualizar el estado, como OBTENER delete.php?id=5para eliminar una página, es muy arriesgado. La gente lo descubrió cuando el acelerador web de Google comenzó a buscar previamente las URL en las páginas: golpeó todos los enlaces de "eliminación" y borró los datos de las personas. Lo mismo puede suceder con las arañas de los motores de búsqueda.

POST puede mover datos grandes mientras que GET no.

Pero generalmente no se trata de una deficiencia de GET, sino de una convención si desea que su sitio web / aplicación web se comporte bien.

Echa un vistazo a http://www.w3.org/2001/tag/doc/whenToUseGet.html

De RFC 2616 :

9.3 GET
El método GET significa recuperar cualquier información (en forma de entidad) identificada por el URI de solicitud. Si el URI de solicitud se refiere a un proceso de producción de datos, son los datos producidos los que se devolverán como la entidad en la respuesta y no el texto fuente del proceso, a menos que ese texto sea el resultado del proceso.

9.5 POST
El método POST se utiliza para solicitar que el servidor de origen acepte la entidad incluida en la solicitud como un nuevo subordinado del recurso identificado por el URI de solicitud en la línea de solicitud. POST está diseñado para permitir un método uniforme para cubrir las siguientes funciones:

• Anotación de recursos existentes;
• Publicar un mensaje en un tablón de anuncios, grupo de noticias, lista de correo o grupo similar de artículos;
• Proporcionar un bloque de datos, como el resultado de enviar un formulario, a un proceso de manejo de datos;
• Extender una base de datos a través de una operación de agregar.

La función real realizada por el método POST la determina el servidor y, por lo general, depende del URI de solicitud. La entidad publicada está subordinada a ese URI de la misma manera que un archivo está subordinado a un directorio que lo contiene, un artículo de noticias está subordinado a un grupo de noticias en el que está publicado o un registro está subordinado a una base de datos.

La acción realizada por el método POST podría no dar como resultado un recurso que pueda ser identificado por un URI. En este caso, 200 (OK) o 204 (Sin contenido) es el estado de respuesta apropiado, dependiendo de si la respuesta incluye o no una entidad que describa el resultado.

Uso POST cuando no quiero que las personas vean QueryString o cuando QueryString se agrande. Además, POST es necesario para cargar archivos.

Sin embargo, no veo ningún problema con GET, lo uso para cosas simples en las que tiene sentido mantener las cosas en QueryString.

El uso de GET también permitirá vincular a una página en particular donde POST no funcionaría.

La intención original era que GET se usara para recuperar datos y POST sería cualquier cosa. La regla general que uso es que si estoy enviando algo de vuelta al servidor, uso POST. Si solo estoy llamando a una URL para recuperar datos, uso GET.

Lea el artículo sobre HTTP en Wikipedia . Explicará qué es el protocolo y qué hace:

OBTENER

Solicita una representación del recurso especificado. Tenga en cuenta que GET no debe usarse para operaciones que causan 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, lo que no debería tener en cuenta los efectos secundarios que debería causar una solicitud.

y

POST Envía datos para procesar (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 las actualizaciones de los recursos existentes o ambos.

El W3C tiene un documento llamado URI, direccionabilidad y el uso de HTTP GET y POST que explica cuándo usar qué. Citando

1.3 Lista de verificación rápida para elegir HTTP GET o POST

• Use GET si:
  • La interacción es más como una pregunta (es decir, es una operación segura, como una consulta, una operación de lectura o una búsqueda).

y

• Use POST si:
  • La interacción es más como una orden, o
  • La interacción cambia el estado del recurso de una manera que el usuario percibiría (por ejemplo, una suscripción a un servicio), o o El usuario debe rendir cuentas por los resultados de la interacción.

Sin embargo, antes de la decisión final de utilizar HTTP GET o POST, también tenga en cuenta los datos confidenciales y las consideraciones prácticas.

Un ejemplo práctico sería cada vez que envíe un formulario HTML. Puede especificar publicar u obtener para la acción del formulario. PHP completará $ _GET y $ _POST en consecuencia.

En PHP, POSTel límite de datos generalmente lo establece su php.ini. GETcreo que está limitado por la configuración del servidor / navegador, generalmente alrededor de 255bytes.

Desde w3schools.com :

¿Qué es el HTTP?

El Protocolo de transferencia de hipertexto (HTTP) está diseñado para permitir las comunicaciones entre clientes y servidores.

HTTP funciona como un protocolo de solicitud-respuesta entre un cliente y un servidor.

Un navegador web puede ser el cliente, y una aplicación en una computadora que aloja un sitio web puede ser el servidor.

Ejemplo: un cliente (navegador) envía una solicitud HTTP al servidor; entonces el servidor devuelve una respuesta al cliente. La respuesta contiene información de estado sobre la solicitud y también puede contener el contenido solicitado.

Dos métodos de solicitud HTTP: GET y POST

Dos métodos comúnmente utilizados para una solicitud-respuesta entre un cliente y un servidor son: GET y POST.

GET: solicita datos de un recurso específico POST: envía datos para procesarlos en un recurso específico

Aquí distinguimos las principales diferencias:

Versión simple de POST GET PUT DELETE

• use GET: cuando desee obtener cualquier recurso como la Lista de datos basada en cualquier Id. o Nombre
• use POST - cuando desee enviar cualquier dato al servidor. tenga en cuenta que POST es una operación pesada porque para la actualización debemos usar PUT en lugar de POST internamente. POST creará un nuevo recurso
• use PUT - cuando

Bueno, una cosa importante es que cualquier cosa que envíe GETse expondrá a través de la URL. En segundo lugar, como dice Ceejayoz, hay un límite de caracteres para una URL.

Otra diferencia es que POST generalmente requiere dos operaciones HTTP, mientras que GET solo requiere una.

Editar: debería aclarar, para los patrones de programación comunes. En general, responder a un POST con una página web HTML directa es un diseño cuestionable por una variedad de razones, una de las cuales es el molesto "debe volver a enviar este formulario, ¿desea hacerlo?" Al presionar el botón Atrás.

Como respondieron otros, hay un límite en el tamaño de la URL con get, y los archivos se pueden enviar solo con publicación.

Me gustaría agregar que uno puede agregar cosas a una base de datos con un get y realizar acciones con una publicación. Cuando un script recibe una publicación o un get, puede hacer lo que el autor quiera que haga. Creo que la falta de comprensión proviene de la redacción que eligió el libro o de cómo lo leyó.

Un autor de guiones debe usar publicaciones para cambiar la base de datos y usar get solo para recuperar información.

Los lenguajes de secuencias de comandos proporcionaron muchos medios para acceder a la solicitud. Por ejemplo, PHP permite el uso de $_REQUESTrecuperar una publicación o un get. Uno debería evitar esto a favor de los más específicos$_GET o $_POST.

En la programación web, hay mucho más espacio para la interpretación. Hay lo que uno debería y lo que uno puede hacer, pero cuál es mejor es a menudo un debate. Afortunadamente, en este caso, no hay ambigüedad. Usted debe usar mensajes para cambiar los datos, y se debe utilizar para conseguir recuperar la información.

Gorgapor, mod_rewritetodavía se utiliza a menudo GET. Simplemente permite traducir una URL más amigable en una URL con una GETcadena de consulta.

Los datos de publicación HTTP no tienen un límite específico en la cantidad de datos, mientras que los diferentes navegadores tienen límites diferentes para GET. El RFC 2068 establece:

Los servidores deben tener cuidado al depender de las longitudes de URI superiores a 255 bytes, porque algunas implementaciones de cliente o proxy más antiguas pueden no ser compatibles con estas longitudes

Específicamente, debe utilizar las construcciones HTTP correctas para lo que se usan. HTTP GET no debería tener efectos secundarios y puede ser actualizado y almacenado de manera segura por HTTP Proxies, etc.

Los POST de HTTP se usan cuando desea enviar datos contra un recurso de URL.

Un ejemplo típico para usar HTTP GET es en una búsqueda, es decir, Buscar? Consulta = my + query Un ejemplo típico para usar un HTTP POST es enviar comentarios a un formulario en línea.