Hasta ahora he visto la respuesta correcta a la que se alude repetidamente, y casi todos se han avergonzado de lo que yo considero subjetivamente la marca.
Empecemos con lo básico:
Una solicitud HTTP puede ser cualquiera de los verbos HTTP , pero los dos que la gente usa más son GET y POST. Bueno, esos son los dos que un programador usa con más frecuencia. Todos los demás tienen algún propósito, si se implementan en el servidor. Cuando envía información al servidor, puede hacerlo a través del uso de la URL (para solicitar una página) o dentro del cuerpo de la solicitud (POST, PUT, DELETE, por ejemplo).
Ahora observará (estoy seguro) que la URL en una solicitud GET a menudo contiene datos, y esto es cierto, pero de acuerdo con W3C, no debe usar GET para alterar el estado y, sin embargo, lo hacemos a menudo. Es una especie de truco que todos estamos de acuerdo en que es un uso real, no un truco. Si eso lo convierte en un truco o un detalle de implementación real, lo dejo a usted.
Entonces, cuando envía el cuerpo del POST (omitiendo los demás por ahora, puede averiguarlo desde aquí) con los elementos del formulario, está devolviendo ciertos elementos. Como estos elementos se definen depende de usted y para el medio ambiente que se está trabajando. Usted podría publicar en un servidor con un elemento de JSON en el cuerpo, o con XML, o con campos de formulario. Generalmente hacemos publicaciones desde un elemento FORM en el cuerpo del HTML.
Ahora todo el mundo dice: "Oh, una devolución de datos es una solicitud posterior a una página". Pero eso no es cierto. Una devolución de datos es cuando envía datos a través de POST -> de vuelta al servidor. Digo esto porque la diferencia entre una solicitud GET y una solicitud POST es si los datos están incluidos en el cuerpo (y el verbo utilizado, pero el cliente generalmente sabe cómo lidiar con eso). Usted podría devolución de datos a la página en la primera vez que la página es visitada, y de hecho ASP.NET tiene herramientas para hacer que en la biblioteca. Ciertamente, podría tener datos POST de un cliente de escritorio en un servidor (piense en Twitter) sin mostrar ninguna página web desde el servidor (de acuerdo, entonces Twitter probablemente no sea el mejor concepto para usar como ejemplo aquí, pero quiero ilustrar que usted puede usar un cliente que no muestra la página web, por lo que no es necesaria ninguna solicitud).
Entonces, realmente lo que debería leer allí en "postback" es "Estoy PUBLICANDO datos DEVOLVER al servidor para su procesamiento". Se presume que recuperó la página inicialmente con un GET para mostrarle al usuario el <form>elemento que tiene <input>campos con los que interactuar, y que al final está devolviendo datos. Pero espero que pueda ver que no tiene que estar en ese orden.
Entonces, aquí hay algo más a considerar:
¿Qué pasa si le dio al usuario una página con un montón de <input>s y ningún <form>pero en cambio, tenía un botón de cableado en javascript a concat todas esas <input>s con &value-n=y enviarlos como un GET? Hace lo mismo, pero viola el concepto de usar GET solo para solicitudes. (posiblemente) la discusión subsiguiente me anima a reforzar que GET no debería tener efectos secundarios (no actualizar los valores)
Es por eso que puedes enviarle a alguien un enlace a una búsqueda de Google, por ejemplo. Por lo tanto, no SIEMPRE tenemos que REGRESAR al servidor para obtener datos.
Espero que esto ayude. Salud