2008-10-12 12 views

Respuesta

23

Por lo general, configuro la pregunta como sigue: ¿Hay algo importante que cambie después de la solicitud? (No obstante, registro y similares). Si lo hace, debe ser una solicitud POST, si no lo hace, debe ser una solicitud GET.

Me complace que llame a las solicitudes POST "ligeramente" más seguras, porque eso es más o menos lo que son; es trivial falsificar una solicitud POST de un usuario a una página. Sin embargo, al hacer una solicitud POST, evita que los aceleradores web o las recargas vuelvan a desencadenar la acción accidentalmente.

Como AJAX, hay una consideración más: si devuelve JSON con soporte de devolución de llamada, tenga mucho cuidado de no poner ningún dato confidencial que no desee que otros sitios web puedan ver allí. Wikipedia tenía una vulnerabilidad en estas líneas donde el token anti CSRF del usuario se reveló a través de su API JSON.

4

Tal vez lo más importante es que GET se puede marcar o ver en el historial de la url y se puede buscar con Google.

POST es importante cuando usted no quiere caso de ser bookmarkable o capaz de ser escrito en una URL - de lo contrario (o Google rastree las URL) podría terminar accidentalmente haciendo cosas como eliminar usuarios de su sistema, por ejemplo.

+0

marcadores en realidad no tiene que ver con AJAX como el Interlocutor pidió. – HalfBrian

+0

No es cierto, si no quiere hacer caso omiso de la espalda/adelante botones en sus aplicaciones AJAX Si no es así, debe usar los valores hash en sus URL, que están directamente relacionados con la URL GET y los marcadores. – jvenema

13

Debe usar GET cuando realiza una solicitud que no tiene efectos secundarios, p. solo buscando algo de información. Esta solicitud puede:

  • repetirse sin ningún problema - si el navegador detecta un error que puede volver a intentar en silencio
  • Han su resultado en caché por el navegador
  • tener una caché mediante un proxy

Estas cosas son todas buenas Cualquier cosa que solo recupere datos (particularmente datos públicos) realmente debería ser un GET. El servidor debe enviar los últimos modificados Last: y Expires: headers para permitir el almacenamiento en caché si es necesario.

6

Las solicitudes POST son tan inseguras como los GET. La principal diferencia es que POST se utiliza para modificar el estado de la aplicación de servidor, mientras que GET solo solicita datos de esta.

La diferencia es importante cuando utiliza URL limpias y "relajadas", donde la URL especifica el recurso y los diferentes métodos desencadenan diferentes acciones en el lado del servidor.

+0

> Las solicitudes POST son tan inseguras como los GET. No es del todo cierto, pero entiendo su punto. las solicitudes a menudo tienen sus datos grabados en archivos de registro de solicitud de acceso inseguro, mientras que los POST generalmente no lo hacen. – Jason

+0

POST y GET no son intrínsecamente seguros o inseguros. Usar uno u otro no tiene absolutamente ninguna conexión con la seguridad – Kibbee

7

Hay otra diferencia no mencionada por nadie.

Las solicitudes GET se pasan en la cadena URL y, por lo tanto, están sujetas a un límite de longitud que generalmente depende del navegador.

Las solicitudes de POST pueden ser mucho más grandes, de hecho, no están realmente limitadas.Entonces, si necesita solicitar datos de un servidor web y está transfiriendo mucha información de parámetros, entonces una solicitud POST podría ser la única opción.

Por lo tanto, como se mencionó anteriormente realmente una solicitud GET es para solicitar datos (sin efectos secundarios) mientras que una solicitud POST generalmente se usa para transmitir datos al servidor que se almacenará (con efectos secundarios). p.ej. Use POST para cargar un archivo. GET para recuperar un archivo.

Hubo un momento en que IE creo que tenía una cadena GET URL muy corta. Algunas aplicaciones, como las notas de Lotus, usan grandes números de caracteres aleatorios para representar las identificaciones de documentos. Tuve el disgusto de usar otro producto que generara cadenas aleatorias, por lo que la URL de la página era única cada vez. La cadena aleatoria era ENORME ... y no siempre funcionaba con IE6 desde la memoria.

8

Todos los buenos puntos, sin embargo, en respuesta a la pregunta, peticiones GET son más útiles en ciertos escenarios sobre las peticiones POST:

  1. Ellos se pueden marcar
  2. Se pueden almacenar en caché
  3. Ellos' es más rápido
  4. Han tenido consecuencias (suponiendo que no cambian los datos), por lo que visitarlos varias veces no es un problema.

Por el bien de la posteridad, la actualización de este comentario con las notas del blog Re: el punto # 3 aquí, todo el crédito a Omar al Zabir (el autor de la blog post referencia):

"Atlas de predeterminado hace HTTP POST para todas las llamadas AJAX. Http POST es más caro que Http GET. Transmite más bytes a través del cable, , lo que le quita un precioso tiempo de red y también hace que ASP.NET realice un procesamiento adicional en el extremo del servidor. , debe usar Http Obtenga hasta posible. Sin embargo, Http Get no le permite pasar objetos como parámetros. Puede pasar números, cadenas y fechas solamente. Cuando realiza una llamada Get Http, Atlas crea una url codificada y da un golpe a la url . Por lo tanto, no debe pasar demasiado contenido que hace que la URL se convierta en más grande que 2048 caracteres. Hasta donde yo sé, esa es la longitud máxima de cualquier url .

Otra cosa malvada acerca de http post es que en realidad son 2 llamadas. El primer navegador envía los encabezados y las respuestas del servidor http con "HTTP 100 Continuar". Cuando el navegador recibe esto, se envía el cuerpo real."

+0

"Son rápidos er "solo porque se puede almacenar en caché? – Harold

+2

No, también por la forma en que funcionan; son completamente diferentes en qué y cómo envían datos. Ver http: // omaralzabir.com/atlas_2__http_post_is_slower_and_it_s_default_in_atlas/ – jvenema

+2

Esta es la única respuesta que responde la pregunta de OP. Otros están hablando de la diferencia. –

Cuestiones relacionadas