form http-post http-get

http post - form - ¿Cuándo usa POST y cuándo usa GET?



form post (27)

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

  1. Nunca use GET y use POST
  2. Nunca uses POST y usa GET
  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?

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

Usarlo para actualizar el estado, como un GET de delete.php?id=5 para eliminar una página, es muy arriesgado. La gente lo descubrió cuando el acelerador web de Google comenzó a buscar URLs en las páginas, ya que afectó a todos los enlaces ''eliminar'' y borró los datos de las personas. Lo mismo puede pasar con las arañas de los buscadores.

Version corta

GET: generalmente se utiliza para las solicitudes de búsqueda enviadas, o cualquier solicitud en la que desee 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:

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

Ventajas de POST:

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

Desventajas de POST:

  • La página que usó datos POST no puede ser marcada. (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 una entidad) identificada por el URI de solicitud. Si la 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 el texto de origen del proceso, a menos que ese texto sea la salida 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 el (los) campo (s) de encabezado condicional. El método GET condicional está destinado a reducir el uso innecesario de la red al permitir que las entidades almacenadas en caché se actualicen sin requerir múltiples solicitudes o 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 de rango. Un GET parcial solicita que solo una parte de la entidad sea transferida, 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 las entidades recuperadas parcialmente sin transferir los datos que ya posee el cliente.

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

Vea la sección 15.1.3 para consideraciones de seguridad cuando se usa 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 los recursos existentes;

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

  • 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 anexión.

La función real realizada por el método POST está determinada por el servidor 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 en el que está publicado o un registro está subordinado a una base de datos.

La acción realizada por el método POST puede no resultar en un recurso que puede ser identificado por un URI. En este caso, 200 (OK) o 204 (Sin contenido) es el estado de respuesta adecuado, dependiendo de si la respuesta incluye o no una entidad que describe el resultado.

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).

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.

Source

Además de la diferencia de restricciones de longitud en muchos navegadores web, también hay una diferencia semántica. Se supone que los GET son "seguros" porque son operaciones de solo lectura que no cambian el estado del servidor. Por lo general, los POST cambiarán de estado y darán advertencias sobre la nueva presentación. Los rastreadores web de los motores de búsqueda pueden generar GET, pero nunca deben realizar POST.

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

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

De RFC 2616 :

9.3 OBTENER
El método GET significa recuperar cualquier información (en forma de una entidad) identificada por el URI de solicitud. Si la 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 el texto de origen del proceso, a menos que ese texto sea la salida 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 los recursos existentes;
  • Publicación de un mensaje en un tablón de anuncios, grupo de noticias, lista de correo o grupo de artículos similares;
  • 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 anexión.

La función real realizada por el método POST está determinada por el servidor 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 en el que está publicado o un registro está subordinado a una base de datos.

La acción realizada por el método POST puede no resultar en un recurso que puede ser identificado por un URI. En este caso, 200 (OK) o 204 (Sin contenido) es el estado de respuesta adecuado, dependiendo de si la respuesta incluye o no una entidad que describe el resultado.

Debido a que los GET son puramente URL, pueden ser almacenados en caché por el navegador web y pueden ser mejor utilizados 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 ligeramente 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.

Transferir más datos de los que debería usar un POST para obtener una mejor compatibilidad con el 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 de Brower, como la historia.

Desde w3schools.com :

¿Qué es 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 ser procesados ​​a un recurso específico

Aquí distinguimos las principales diferencias:

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

Esto atraviesa el concepto de REST y la forma en que la web estaba destinada a ser utilizada. Hay un excelente podcast en la radio de Ingeniería de Software que brinda una charla profunda sobre el uso de Get and 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 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 enviarla fácilmente a otros sistemas y personas, como una dirección donde encontrar algo.

Se supone que la publicación se usa (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.

La intención original era que se utilizara GET para recuperar datos y POST debía ser cualquier cosa. La regla de oro que uso es que si envío algo al servidor, uso POST. Si estoy llamando a una URL para recuperar datos, uso GET.

Lea el artículo sobre HTTP en la 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, que no deberían tener en cuenta los efectos secundarios que debería causar una solicitud.

y

POST Envía datos para ser procesados ​​(por ejemplo, desde un formulario HTML) al recurso identificado. Los datos están incluidos 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 w3.org/2001/tag/doc/whenToUseGet.html que 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, 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 será responsable por los resultados de la interacción.

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

Un ejemplo práctico sería cada vez que envíe un formulario HTML. Usted especifica ya sea post u obtener para la acción de formulario. PHP llenará $ _GET y $ _POST en consecuencia.

Lo primero importante es el significado de GET versus POST:

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


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

  • Usando GET, sus 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á usando con los parámetros en la cadena de consulta, todos los días; sin GET, todas esas no funcionarían ;-)

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

No hay nada que no puedas hacer per se. El punto es que no debes modificar el estado del servidor en un HTTP GET. Los proxies HTTP asumen 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. Usando esta información, asumen que es seguro devolver una versión en caché del primer HTTP GET. Si rompe la especificación HTTP, se arriesga a romper el cliente HTTP y los proxies en la naturaleza. No lo hagas :)

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

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

POST puede mover datos grandes, mientras que GET no puede.

Pero, en general, 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.

Eche un vistazo a w3.org/2001/tag/doc/whenToUseGet.html

Según lo contestado por otros, hay un límite en el tamaño de URL con get, y los archivos solo pueden enviarse con publicaciones.

Me gustaría agregar que uno puede agregar cosas a una base de datos con una acción de obtener y realizar con una publicación.Cuando un guión recibe una publicación o una obtención, 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 se lee.

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

Los lenguajes de script proporcionaron muchos medios para acceder a la solicitud. Por ejemplo, PHP permite el uso de $_REQUESTpara recuperar una publicación o una obtención. Se debe evitar esto a favor de lo más específico $_GETo $_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 a menudo es tema de debate. Por suerte, 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.

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 ciertamente es posible golpearla si tienes textarea s en tus formularios.

Otro problema con los GET: son indexados por los motores de búsqueda y otros sistemas automáticos. Una vez, Google tenía un producto que pre-buscaba enlaces en la página que estaba viendo, por lo que serían más rápidos de cargar si hacía clic en esos enlaces. Causó grandes estragos en sitios que tenían enlaces como delete.php?id=1 : las personas perdieron todos sus sitios.

Use POST para acciones destructivas como la creación (soy consciente de la ironía), la edición y la eliminación, porque no puede realizar una acción POST en la barra de direcciones de su navegador. Use GET cuando sea seguro permitir que una persona llame a una acción. Así que 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.

POST también es más seguro que GET , porque no está pegando información en una URL. Y así, no es la mejor idea usar GET como method para un formulario HTML que recopila una contraseña u otra información confidencial.

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.

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

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

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 usar un 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.

Utilizo POST cuando no quiero que las personas vean QueryString o cuando QueryString se hace grande. Además, se necesita POST para subir archivos.

Sin embargo, no veo un problema al usar GET, lo uso para cosas simples donde tiene sentido mantener las cosas en el QueryString.

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

Versión simple de POST GET PUT DELETE

  • use GET - cuando quiera obtener algún recurso como la Lista de datos en función de cualquier Id o Nombre
  • use POST - cuando quiera enviar cualquier dato al servidor. tenga en cuenta que POST es una operación de gran peso porque para la actualización debemos usar PUT en lugar de POST internamente. POST creará un nuevo recurso
  • utilizar PUT - cuando

En breve

  • Utilice GET para solicitudes safe and idempotent
  • No utilice POST para POST neither safe nor idempotent

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

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

Una operación safe es una operación que not change the data solicitados.

Una operación idempotent es aquella en la que el resultado será be the same sin importar cuántas veces lo solicite.

Es lógico que, como los GET se usan 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 pila, por ejemplo) o la recopilación de recursos.

Una aplicación RESTful utilizará PUTs para operaciones que not safe but idempotent 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 usa para editar un recurso (por ejemplo, editar una pregunta o una respuesta en el desbordamiento de pila).

Se usaría un POST para cualquier operación que neither safe or idempotent .

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

Si ejecuta el POST dos veces, terminará 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 de javascript, pero en términos de ingresar datos en formularios y presionar enviar, generalmente tiene las dos opciones). En una aplicación REST, el POST a menudo se anulará para proporcionar las llamadas PUT y DELETE también.

Pero, incluso si no está siguiendo los principios REST, puede ser útil pensar en términos de usar GET para recuperar / ver información y POST para crear / editar información.

Nunca debe usar GET para una operación que altere 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.

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

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

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

Específicamente, debe usar las construcciones HTTP correctas para lo que se usan. Los HTTP GET no deberían tener efectos secundarios y pueden ser actualizados y almacenados de manera segura por HTTP Proxies, etc.

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

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