¿Por qué hay solicitudes GET y POST en AJAX, ya que no afecta la URL de la página de todos modos? ¿Qué diferencia hace al pasar datos sensibles sobre GET en AJAX ya que los datos no se reflejan en la URL de la página?GET vs POST en AJAX?
Debe usar el verbo HTTP adecuado según lo que necesite de su servicio web.
Cuando se trata de una colección URI como: http://example.com/resources/
GET: Liste los miembros de la colección, completa con sus URIs miembros para obtener una navegación más. Por ejemplo, enumere todos los autos en venta.
PUT: Significado definido como "reemplazar toda la colección con otra colección".
POST: Cree una nueva entrada en la colección donde el ID se asigna automáticamente por la colección. La ID creada generalmente se incluye como parte de los datos devueltos por esta operación.
DELETE: Significado definido como "eliminar toda la colección".
Cuando se trata de un miembro URI como: http://example.com/resources/7HOU57Y
GET: Recuperar una representación del miembro requerido de la colección se expresa en un tipo MIME apropiado.
PUT: Actualice el miembro direccionado de la colección o créelo con la ID especificada.
POST: Trata al miembro direccionado como una colección en sí mismo y crea un nuevo subordinado del mismo.
BORRAR: Eliminar el miembro requerido de la colección.
Fuente: Wikipedia
Bueno, en cuanto a GET, usted todavía tiene la limitación de longitud de url. Aparte de eso, es bastante concebible que el servidor trate las solicitudes POST y GET de forma diferente; por lo tanto, la necesidad de poder especificar qué pedido estás haciendo.
Además, puede utilizar ambos tipos de solicitud al desarrollar la aplicación. Para la mayoría de ellos, la bandera 'is_ajax' es suficiente. Es mejor tener esa opción que no tener. –
Acepto la respuesta de dnl.vssll porque la limitación de longitud de la URL GET no está impuesta por HTTP o AJAX, puede verificar esta respuesta para que http://stackoverflow.com/questions/812925/what-is-the-maximum-possible- length-of-a-query-string. Está limitado por navegador/servidor y por qué es limitado es realmente un punto de discusión ..como HTTP está basado en texto, el navegador envía la solicitud HTTP como un todo. Incluye cadena de consulta, de modo que si no hay límite en la duración de la solicitud (asumiendo el caso ideal) ¿cuál es el sentido de limitar la cadena de consulta? – Xinus
no estaba argumentando para defender el límite de longitud, solo estaba diciendo que estaba allí, y que tendrá que considerarlo, porque al hacer un desarrollo web, realmente no puede permitirse ignorar * navegadores *. pero bueno, no necesitas motivar a tus acepta; La respuesta de dnl también fue buena =) –
dos razones principales para tenerlos:
GET solicitudes tienen algunas limitaciones bastante restrictivos en tamaño; POST suelen ser capaces de contener mucha más información.
El backend puede estar esperando GET o POST, dependiendo de cómo se haya diseñado. Necesitamos la flexibilidad de hacer un GET si el backend espera uno, o un POST si eso es lo que está esperando.
Normalmente se envía parámetros al script AJAX, devuelve los datos en base a estos parámetros. Funciona igual que un formulario que tiene method = "get" o method = "post". Al usar el método GET, los parámetros se pasan en la cadena de consulta. Cuando se utiliza el método POST, los parámetros se envían en el cuerpo de la publicación.
Generalmente, si sus parámetros tienen muy pocos caracteres y no contienen información sensible, entonces los envía a través del método GET. Los datos confidenciales (por ejemplo, la contraseña) o el texto largo (por ejemplo, una biografía larga de 8000 caracteres de una persona) se envían mejor a través del método POST.
Los métodos AFAIK GET y POST difieren solo en su formato de solicitud, por lo que no creo que POST sea más seguro que GET. GET se considera inseguro porque los parámetros se reflejan en la URL, pero AJAX supera ese problema. Además, todos los navegadores modernos no limitan la cantidad de datos que podemos enviar a través de la solicitud GET ... La única explicación posible que pude ver a partir de las respuestas es que AJAX está diseñado para existir con un protocolo HTTP bien establecido ... lo cual es lógico. – Xinus
@Xinus: La última vez que escuché, los dos navegadores * y * todavía impusieron límites significativos de longitud de URL (por ejemplo, 'GET'), al igual que la especificación HTTP IIRC. ¿Puedes publicar una referencia para tu declaración que dicen que no? –
Tienes razón. Pero la razón por la que algunas personas consideran que POST es * ligeramente * más seguro que GET es porque los parámetros GET pueden almacenarse en varias ubicaciones, incluidos los registros del servidor y el historial del navegador como URL. POST no tiene este problema. –
Otros han cubierto los puntos principales (contexto/idempotencia, y tamaño), pero agregaré otro: cifrado. Si usa SSL y desea encriptar sus args de entrada, necesita usar POST.
Esto es incorrecto. Todos los datos transferidos a través de SSL están encriptados. GET vs POST no hace diferencia alguna. –
Estoy de acuerdo con Joel L. Toda la comunicación está encriptada entonces, ¿dónde está la pregunta de qué método se usó? – Xinus
Otra diferencia entre GET y POST es la forma en que se maneja el almacenamiento en caché en los navegadores. POST la respuesta nunca se almacena en caché. GET puede o no almacenarse en caché según las reglas de almacenamiento en caché especificadas en sus encabezados de respuesta.
Cuando utilizamos el método GET en Ajax, solo se envía el contenido del valor del campo, no el formato en el que se encuentra el contenido. Por ejemplo, el contenido en el área de texto se acaba de agregar en la URL en el caso del método GET (sin un nuevo carácter de línea). Ese no es el caso en el método POST.
Gracias .. uso principalmente el método GET con Ajax y no tengo ningún problema hasta ahora, excepto los siguientes:
Internet Explorer (a diferencia de Firefox y Google Chrome) caché obtienen llamadas si se utiliza la misma OBTENER valores
Por lo tanto, usar un intervalo con Ajax GET puede mostrar los mismos resultados a menos que cambie la URL con el uso de números aleatorios irrelevantes para cada Ajax GET.
Simplemente se trata de respetar las reglas del protocolo http.
Obtenga - las llamadas deben ser idempotentes. Esto significa que si lo llamas varias veces obtendrás el mismo resultado. No tiene la intención de cambiar los datos subyacentes. Es posible utilizar esto para un cuadro de búsqueda, etc.
Mensaje - Las llamadas no se idempotente. Está permitido hacer un cambio en los datos subyacentes, por lo que podría usarse en un método de creación. Si lo llamas varias veces, crearás varias entradas.
Los datos se reflejan en la URL de la página usando GET. Eche un vistazo a lo que está sucediendo con un monitor TCP/IP o incluso solo al complemento Header Monitor para Firefox. –
Posible duplicado: http://stackoverflow.com/questions/715335/get-vs-post-in-ajax/ – trante