¿Cuándo usas POST y cuándo usas GET?

StackOverflow https://stackoverflow.com/questions/46585

  •  09-06-2019
  •  | 
  •  

Pregunta

Por lo que puedo deducir, hay tres categorías:

  1. Nunca usar GET y use POST
  2. Nunca usar POST y use GET
  3. No importa cuál uses.

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

¿Fue útil?

Solución

Usar POST para acciones destructivas como la creación (soy consciente de la ironía), la edición y la eliminación, porque no se puede acertar en un POST acción en la barra de direcciones de su navegador.Usar GET cuándo es seguro permitir que una persona solicite 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.De esta manera es mucho más fácil evitar accidentes.

POST También es más seguro que GET, porque no estás insertando información en una URL.Y así usando GET como el method un formulario HTML que recopile una contraseña u otra información confidencial no es la mejor idea.

Una nota final: POST puede 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.

Otros consejos

En breve

  • Usar GET para safe andidempotent peticiones
  • Usar POST para neither safe nor idempotent peticiones

En detallesHay un lugar adecuado para cada uno.Incluso si no sigues Sosegado principios, se puede ganar mucho aprendiendo sobre REST y cómo funciona un enfoque orientado a recursos.

Una aplicación RESTful use GETs para operaciones que son a la vez safe and idempotent.

A safe operación es una operación que no not change the data solicitado.

Un idempotent operación es aquella en la que el resultado será be the same no importa cuantas veces lo solicites.

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

Una aplicación RESTful utilizará PUTs para operaciones que son not safe but idempotent.

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

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

A POST Se utilizaría para cualquier operación que sea neither safe or idempotent.

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

Si ejecuta el POST dos veces, terminará creando DOS preguntas nuevas.

También hay una operación DELETE, pero supongo que puedo dejarla 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 mediante llamadas de 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 resultar útil pensar en términos de utilizar GET para recuperar/ver información y POST para crear/editar información.

Nunca debes usar GET para una operación que altere datos.Si un motor de búsqueda rastrea un enlace a su operación malvada, o el cliente lo marca como favorito, podría significar un gran problema.

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

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

Version corta

CONSEGUIR:Generalmente se usa para solicitudes de búsqueda enviadas o cualquier solicitud en la que desee que el usuario pueda abrir la página exacta nuevamente.

Ventajas de OBTENER:

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

Desventajas de OBTENER:

CORREO:Se utiliza para solicitudes de mayor seguridad en las que los datos pueden usarse para alterar una base de datos o una página que no desea que alguien agregue a favoritos.

Ventajas de la CORREO:

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

Desventajas de la publicación:

  • La página que utilizó datos POST no se puede marcar como favorita.(Si así lo desea).

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, serán los datos producidos los que se devolverán como 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 bajo las circunstancias descritas por los campos de encabezado condicional.El método GET condicional tiene como objetivo reducir el uso innecesario de la red al permitir que las entidades almacenadas en caché se actualicen sin requerir múltiples solicitudes ni transferir datos que ya posee el cliente.

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

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

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

9.5 PUBLICAR

El método de publicación se utiliza para solicitar que el servidor de origen acepte la entidad encerrada en la solicitud como un nuevo subordinado del recurso identificado por la solicitud-URI en la línea de solicitud.Post está diseñado para permitir que un método uniforme cubra 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;

  • Ampliar una base de datos mediante una operación de adición.

El servidor determina la función real realizada por el método POST y generalmente depende de la solicitud-URI.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 al que se publica, 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 puede identificarse 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 describe el resultado.

Lo primero importante es el significado de OBTENER versus POST:

  • GET debe usarse para...conseguir...alguna información de el servidor,
  • mientras que POST debe usarse para enviar alguna información a el servidor.


Después de esto, se pueden señalar un par de cosas:

  • Con GET, sus usuarios pueden usar el botón "atrás" en su navegador y pueden marcar páginas como favoritas.
  • 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 mayor 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, todas ellas no funcionarían ;-)

Aparte de la diferencia en las 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 sólo lectura que no cambian el estado del servidor.Los POST normalmente cambiarán de estado y darán advertencias al volver a enviarlos.Los rastreadores web de los motores de búsqueda pueden generar GET, pero nunca deberían realizar POST.

Utilice GET si desea leer datos sin cambiar el estado y utilice 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 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 ciertamente es posible lograrlo si tienes textareas en sus formularios.

Otro problema con los GET: los motores de búsqueda y otros sistemas automáticos los indexan.Google alguna vez tuvo un producto que buscaba previamente enlaces en la página que estabas viendo, por lo que se cargarían más rápido si hacías clic en esos enlaces.Causó importante estragos en sitios que tenían enlaces como delete.php?id=1 - la gente perdió sus sitios completos.

Utilice 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 utilizar 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ámetro después de la ruta.

Debido a que los GET son puramente URL, el navegador web puede almacenarlos en caché y pueden usarse mejor para cosas como imágenes generadas de manera consistente.(Establezca una hora de caducidad)

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

GET puede producir 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 según el estándar, aunque los navegadores pueden admitir más.

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

Incluso menos de ese límite es un problema, como escribió otro usuario, 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 caso es que no lo eres supuesto para modificar el estado del servidor en un HTTP GET.Los servidores proxy HTTP suponen que, dado que HTTP GET no modifica el estado, no hay diferencia si un usuario invoca HTTP GET una o 1000 veces.Al utilizar esta información, asumen que es seguro devolver una versión en caché del primer HTTP GET.Si infringe 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 se pretendía utilizar la web.Hay una excelente podcast en la radio Ingeniería de Software que brinda una charla en profundidad sobre el uso de Get y Post.

Get se utiliza para extraer datos del servidor, donde no debería ser necesaria una acción de actualización.La idea es que debería poder utilizar la misma solicitud GET una y otra vez y obtener 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 la publicación debe usarse (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:Actualice estos datos, cree este registro.

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

Utilice GET si:

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

Utilice 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 ningún problema al usar get, lo uso para cosas simples en las que tiene sentido mantener cosas en la cadena de consulta.

Utilizándolo para actualizar el estado, como un GET de delete.php?id=5 eliminar una página - es muy arriesgado.La gente se enteró de eso cuando el acelerador web de Google comenzó a buscar previamente las URL de las páginas: presionó 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 grandes cantidades de datos mientras que GET no.

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

Mira esto http://www.w3.org/2001/tag/doc/whenToUseGet.html

De RFC 2616:

9.3 CONSEGUIR
El método GET significa recuperar cualquier información (en la forma de una entidad) identificada por el requisito-URI.Si el Solicitud-URI 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 al texto fuente del proceso, a menos que ese texto sea la salida del proceso.


9.5 CORREO
El método de publicación se utiliza para solicitar que el servidor de origen acepte la entidad encerrada en la solicitud como un nuevo subordinado del recurso identificado por la solicitud-URI en la línea de solicitud.Post está diseñado para permitir que un método uniforme cubra 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;
  • Ampliar una base de datos mediante una operación de adición.

El servidor determina la función real realizada por el método POST y generalmente depende de la solicitud-URI.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 al que se publica, 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 puede identificarse 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 describe el resultado.

Utilizo POST cuando no quiero que la gente vea QueryString o cuando QueryString se hace grande.Además, se necesita POST para cargar archivos.

Sin embargo, no veo ningún problema al usar 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.

Versión simple de POST GET PUT DELETE

  • use GET: cuando desee obtener cualquier recurso como una lista de datos basada en cualquier ID o nombre
  • use POST - cuando desee enviar datos al servidor.Mantener en Mind Post es una operación de peso pesado porque para la actualización debemos usar en lugar de publicar internamente la publicación creará nuevos recursos
  • usa PUT - cuando

La intención original era que GET se usara para recuperar datos y POST fuera cualquier cosa.La regla general que uso es que si envío algo al servidor, uso POST.Si solo llamo a una URL para recuperar datos, uso GET.

Leer el artículo sobre HTTP en la Wikipedia.Te explicará qué es el protocolo y qué hace:

CONSEGUIR

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 en cuenta los efectos secundarios que debería causar una solicitud.

y

CORREOEnví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 recursos existentes o ambas.

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

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

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

y

  • Utilice 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 el usuario será responsable de los resultados de la interacción.

Sin embargo, antes de tomar la decisión final de utilizar HTTP GET o POST, considere también consideraciones sobre datos confidenciales y consideraciones prácticas.

Un ejemplo práctico sería cada vez que envíe un formulario HTML.Usted especifica cualquiera de los dos correo o conseguir para la acción del formulario.PHP completará $_GET y $_POST en consecuencia.

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

De w3schools.com:

¿Qué es HTTP?

El Protocolo de transferencia de hipertexto (HTTP) está diseñado para habilitar 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;luego 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:OBTENER y PUBLICAR

Dos métodos de uso común para una respuesta de solicitud entre un cliente y un servidor son:OBTENER y PUBLICAR.

Obtener - Solicitud de datos de una publicación de recursos especificada - envía datos para ser procesados ​​a un recurso especificado

Aquí distinguimos las principales diferencias:

enter image description here

Bueno, una cosa importante es cualquier cosa que envíes. GET se 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:Debo aclarar... para patrones de programación comunes.En general, responder a una publicación con una página web HTML directa es un diseño cuestionable por una variedad de razones, una de las cuales es la molesta "Debes volver a enviar este formulario, ¿quieres 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 solo se pueden enviar con publicación.

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

Un autor de guión debería use publicaciones para cambiar la base de datos y use get solo para recuperar información.

Los lenguajes de programación proporcionaron muchos medios para acceder a la solicitud.Por ejemplo, PHP permite el uso de $_REQUEST para recuperar una publicación o un get.Se debería evitar esto en favor de las más específicas. $_GET o $_POST.

En la programación web, hay mucho más espacio para la interpretación.Hay lo que uno debería y cual poder hacer, pero cuál es mejor es a menudo objeto de debate.Por suerte, en este caso no hay ambigüedad.Tú debería usa publicaciones para cambiar datos, y tú debería Utilice get para recuperar información.

Gorgapor, mod_rewrite todavía utiliza a menudo GET.Simplemente permite traducir una URL más amigable a una URL con un GET cadena de consulta.

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

Los servidores deben tener cuidado con depender de longitudes de URI por encima de 255 bytes, porque algunas implementaciones de clientes o proxy pueden no admitir correctamente estas longitudes

Específicamente, debe utilizar las construcciones HTTP correctas para el uso que se les da.Los HTTP GET no deberían tener efectos secundarios y pueden actualizarse y almacenarse de forma segura mediante servidores proxy HTTP, etc.

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

Un ejemplo típico de uso de HTTP GET es en una búsqueda, es decir.Buscar? Query = my+consulta Un ejemplo típico para usar una publicación HTTP está enviando comentarios a un formulario en línea.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top