Até agora eu vi a resposta certa aludida repetidamente, e quase todo mundo ficou tímido quanto ao que considero subjetivamente ser o alvo.
Vamos começar com o básico:
Uma solicitação HTTP pode ser qualquer um dos verbos HTTP , mas os dois que as pessoas mais usam são GET e POST. Bem, esses são os dois que um programador usa com mais frequência. Todos os outros têm alguma finalidade, se implementados no servidor. Ao enviar informações para o servidor, você pode fazê-lo por meio do uso da URL (para solicitar uma página) ou dentro do corpo da solicitação (POST, PUT, DELETE, por exemplo).
Agora você observará (tenho certeza) que a URL em uma solicitação GET geralmente contém dados, e isso é verdade, mas de acordo com o W3C, você não deve usar GET para alterar o estado, e ainda assim fazemos com frequência. É uma espécie de hack que todos concordamos ser um uso real, e não um hack. Se isso se torna um hack ou um detalhe de implementação real, eu deixo para você.
Então, quando você envia o corpo do POST (ignorando os outros por enquanto, você pode descobrir isso aqui) com os elementos do formulário, você está enviando de volta certos elementos. Como esses elementos são definidos depende de você e do ambiente em que está trabalhando. Você pode postar em um servidor com um elemento JSON no corpo, ou com XML, ou com campos de formulário. Geralmente fazemos postagens de um elemento FORM no corpo do HTML.
Agora todo mundo diz: "ah, um postback é uma solicitação subsequente para uma página". Mas isso não é verdade. Um postback é quando você envia dados via POST -> de volta ao servidor. Digo isso porque a diferença entre uma solicitação GET e uma solicitação POST é se os dados estão incluídos no corpo (e o verbo usado, mas o cliente geralmente sabe como lidar com isso). Você poderia postar na página na primeira vez em que ela fosse visitada e, na verdade, o ASP.NET tem ferramentas para fazer isso na biblioteca. Você certamente poderia ter dados de POST de um cliente de desktop em um servidor (pense no Twitter) sem mostrar nenhuma página da Web do servidor (ok, o Twitter provavelmente não é o melhor conceito para usar como exemplo aqui, mas quero ilustrar que você pode usar um cliente que não mostra a página da web, portanto, nenhuma solicitação é necessária).
Então, o que você realmente deve ler em "postback" é "Estou enviando dados de volta para o servidor para processamento". Presume-se que você recuperou a página inicialmente com um GET para mostrar ao usuário o <form>
elemento que possui <input>
campos para ele interagir e que no final você está enviando dados de volta. Mas espero que você veja que não precisa estar nessa ordem.
Então, aqui está outra coisa a considerar:
O que se deu ao usuário uma página com um monte de <input>
s e nenhum <form>
, mas em vez disso, tinha um botão com fio em javascript para concat todos aqueles <input>
s com &value-n=
e enviá-los como um GET? Faz a mesma coisa, mas viola o conceito de usar apenas GET para solicitações. (possivelmente) a discussão subsequente me incentiva a reforçar que GET não deve ter efeitos colaterais (sem valores de atualização)
É como você pode enviar a alguém um link para uma pesquisa no Google, por exemplo. Portanto, nem SEMPRE precisamos POST BACK para o servidor para obter dados.
Espero que isto ajude. Felicidades