HTTP – Entendendo Post, Get, Status Code e Content-Type    

Para iniciar este post, vou utilizar um texto do livro para a certificação de Asp.Net do framework 3.5 (70-562):

“Um bom desenvolvedor de aplicações Web precisa saber muito mais que apenas sua linguagem preferida para ser um verdadeiro desenvolvedor Web. De fato, C# ou Visual Basic é só o começo. Você precisar saber como criar, gerenciar e implementar interface com CSS. JavaScript também será necessário se você quiser criar suas próprias funcionalidades no lado do Cliente em suas páginas. Você pode também precisar conhecer XML, Web Services e banco de dados. Claro, você também precisa saber como todas essas coisas trabalham juntas para fazer uma única solução. Um desenvolvedor de Web moderno precisa saber mais tecnologias (e ter facilidade de mudar entre elas) do qualquer outro desenvolvedor na história. Eu penso que essa é uma das razões que o desenvolvimento Web é uma experiência tão desafiadora, legal e recompensadora”

--Mike Snell – Microsoft .Net Framework 3.5 – Asp.Net Application Development – Training Kit

É isso que todo desenvolvedor Web deve saber: que ele deve conhecer muitas tecnologias! Como comentei no primeiro post dessa série introdutória à série de posts sobre Asp.Net MVC, a necessidade destes posts introdutórios é que o desenvolvedor Asp.Net saiba que para realmente ser um desenvolvedor Asp.Net ele precisa também ser , antes de qualquer coisa, um desenvolvedor Web, conhecer o funcionamento da Web (pelo menos o Básico).

Então vamos ao tema do post!

Aplicações Web não são como aplicações Windows, elas não rodam em um processo único nem em uma máquina única. Normalmente elas são hospedadas em um servidor Web e acessadas através de um navegador. A comunicação é feita através do protocolo HTTP (Hypertext Transfer Protocol). É necessário saber como essa comunicação é feita antes de você sair fazendo páginas que sobrecarregam a comunicação. Uma comunicação típica entre o navegador e servidor pode ser resumida nesses dez passos (retirados do livro acima):

  1. Um usuário solicita uma página ou qualquer recurso (uma imagem, por exemplo) de um servidor Web
  2. HTTP é utilizada para enviar uma requisição (request) GET para o servidor
  3. O servidor processa a requisição GET no servidor (normalmente localizando o código solicitado e executando-o)
  4. O servidor então envia uma resposta (response) de volta ao navegador. O protocolo HTTP é utilizado para enviar a resposta (response) de volta ao navegador.
  5. O navegador do usuário então processa a resposta (response), normalmente HTML e JavaScript, e renderiza a página Web para mostrar ao usuário.
  6. O usuário pode então digitar alguma informação ou realizar alguma ação, como clicar em um botão que causa a informação ser enviada de volta ao servidor para processamento.
  7. HTTP é usada para postar (POST) as informações de volta ao servidor (post back to the server).
  8. O servidor então processa a requisição POST (novamente chamando seu código no processo)
  9. O servidor então envia uma resposta de volta ao browser (response back) . HTTP é utilizada para responder ao navegador.
  10. O navegador novamente processa a resposta e exibe a página ao usuário. Esse processo se repete muitas e muitas vezes no tempo de vida de uma página comum.

Entendendo o papel do Hypertext Transfer Protocol

HTTP é um protocolo de comunicação baseado em mensagens de texto utilizadas para requisitar (Request) páginas do servidor e enviar respostas (Response) ao navegador. Estas mensagens são normalmente trocadas entre o servidor e o navegador  utilizando a porta 80 ou 443 se for utilizada HTTP seguro (HTTPs).

Uma mensagem geralmente é formada por cabeçalho (headers) e corpo (body), e veremos alguns exemplos de como essas mensagens são montadas.

Um comando de texto para requistiar uma página seria o seguinte:

GET /default.aspx HTTP/1.1
Host: www.fredericoemidio.com

A primeira linha tem o que chamamos de método HTTP, conhecido algumas vezes como comando HTTP ou Verbo. O verbo é seguido pela URL da página requisitada, seguida pela versão do HTTP utilizada para processar a requisição. A segunda linha define o nome do host que deve ser utilizado pelo servidor, é importante porque é normal que um servidor tenha mais de um site hospedado.

Toda requisição ao servidor, que a gente chama de Request (estava deixando em negrito para vocês verem a ligação, se não viram, agora viram), tem uma resposta, que a gente chama de Response, também baseado em texto. A requisição acima poderia ter uma resposta assim:

HTTP/1.1 200 OK
Server: Microsoft-IIS/6.0
Content-Type: text/html
Content-Length: 38
<html><body>Seja bem vindo!</body></html>

A primeira linha indica o protocolo de comunicação e a versão. Também inclui o código de status da resposta e o texto do status. A segunda linha, como você pode ver, indica o tipo do servidor, a terceira linha o tipo da resposta e a quarta linha o tamanho da resposta. Daí em diante é o conteúdo da resposta.

É importante conhecer um pouco de Códigos de Status para desenvolver uma boa aplicação Web. Na realidade, conhecendo três informações dessas mensagens, você já saberá bastante para desenvolver uma boa página: O Verbo, os Códigos de Status de Retorno e o Contet-Type. Essas três informações são as mais utilizadas ao desenvolver um bom site, e você terá a explicação delas pelo resto do post. Naturalmente, como os demais posts introdutórios, vou apenas pincelar esse tema de HTTP, se você quiser saber mais, visite o site da W3C, e poderá conhecer tudo sobre isso.

Verbos HTTP

Post e Get são verbos HTTP, e são os mais utilizados por nós, essa é a razão do titulo deste post, vamos entender a diferença.

O GET obtém (get em inglês) uma URL do servidor. Uma requisição GET é normalmente armazenada em cache pelo navegador, se nenhuma informação do Get mudar, o browser pode decidir não requisitar a resposta ao servidor, e utilizar uma versão em memória. GET também pode trabalhar com coleções, com aquelas de diretórios que têm lista de arquivos, apesar de que se você requisitar um diretório, o servidor pode estar configurado para retornar um arquivo padrão, como index.htm.

Quando passamos critérios em uma requisição GET, os parâmetros são passados no endereço da requisição, o que chamados de Querystring, ou seja, se digitarmos default.aspx?teste=1 no navegador, a mensagem HTTP que será enviada será:

GET /default.aspx?teste=1 HTTP/1.1
Host: www.fredericoemidio.com

Tudo que for utilizada depois do símbolo de interrogação (?) será considerado parâmetro para o servidor.

Utilizar GET tem seus prós e seus contras: Se você quiser manter o resultado de uma pesquisa em cache, ou enviar para alguém por e-mail, seria interessante utilizar o GET, por outro lado, se você desejar utilizar muitos campos e valores como critério, não será possível, pois o GET aceita no máximo uma string de 1024 caracteres. Os dados podem também ser facilmente alterados, mesmo os parâmetros podem ser alterados.

O POST é utilizado para postar informações para o servidor. Diferente do GET, o POST envia os dados no corpo da mensagem, não alterando o endereço da requisição, a mesma mensagem acima, se fosse enviada através de POST, seria da seguinte forma:

GET /default.aspx HTTP/1.1
Host: www.fredericoemidio.com
teste=1

Dessa forma, não será possível armazenar em Cache o resultado, porque o navegador não armazena o conteúdo da mensagem, apenas o endereço da mensagem. O POST também não tem limitação de tamanho, foi testado até 10 MB e não foi encontrado problemas. O POST também impede que usuário alterem as informações da mensagem, esse verbo é mais comum para envio de informações de formulários para servidores.

Os formulários em WebForms utilizando o método POST para envio, é por isso que muitas vezes validamos no PageLoad da página se a requisição é um PostBack (Retorno de Post).

Podemos facilmente alterar o verbo do envio de um formulário para o servidor, pois a tag FORM tem um atributo METHOD, que pode ter qualquer verbo HTTP, apesar de usarmos geralmente POST ou GET.

Conhecendo esses dois métodos já podemos fazer bastante coisa. Para trabalhar com Ajax, é o mínimo que você precisa conhecer. Existem muitos outros verbos, que você pode estudar mais tarde, mas conhecendo bem as diferenças desses dois é um bom começo.

Códigos de Retorno

Se você já fez alguma coisa com Ajax (de verdade, não com biblioteca que encapsulam tudo), já teve que trabalhar um pouco com códigos de retorno. Os códigos de status de retorno são agrupados em cinco grupos. Mesmo que você não se lembre todos os códigos, é interessante lembrar pelo menos os grupos. Os códigos são agrupados em grupos de três dígitos, conforme segue:

Cód. Descrição
1xx Informativo: Requisição recebida, continuando a processar
2xx Sucesso: A requisição foi recebida com sucesso, entendida e acatada
3xx Comando de Redirecionar: Ações adicionais devem ser tomadas para completar a requisição
4xx Erro do Cliente: A requisição tem algum erro ou o servidor não entendeu todo o pedido.
5xx Erro do servidor: O servidor falhou em completar uma requisição que parecer ser válida.

Você com certeza já deve ter visto alguns dos códigos acima, como 404 – Página não encontrada, ou 500 – Internal Server Error.

Busque conhecer mais sobre esses erros, pode ser muito útil para a solução de problemas estranhos.

Content-Type

Para finalizar esse post, acredito ser importante falar dos tipos de requisição. No exemplo acima mostrei uma requisição do tipo text/html. O tipo de conteúdo pode mudar muito, não é só HTML.

O indicador do tipo de uma mensagem é na forma de Multipurpose Internet Mail Extensions (MIME), no caso do exemplo (text/html), o arquivo é um arquivo estático de HTML. Os tipos MIME são definidos em duas partes (tipo/sub-tipo), no qual o primeiro tipo é tipo do geral do recurso, e o segundo é o tipo mais específico do recurso. Alguns exemplos do Content-Type são: text/xml, text/json, image/jpeg, etc.

Uma requisição ajax, por exemplo, utiliza um content-type text/json em geral, junto com um verbo POST. Muitas vezes, no MVC podemos querer retornar uma View que seja um gráfico, para isso podemos utilizar um content-type do tipo image/png, ou realizar a mesma coisa com WebForms utilizando um Generic Handler (ashx),alterando o content-type do Response.

Conclusão

Bom, nesse post quis mostrar que na Web pode ter um pouco mais do que você imagina. É claro que se você ainda não sabia do que foi dito aqui, então sabia muito pouco sobre a Web, é bom saber como as coisas funcionam por trás dos panos.

Esse artigo foi basicamente baseado no material para certificação da Microsoft, da prova 70-562. Diferente do que muitos pensam, eu acredito que é muito válido o estudo para as certificações da Microsoft, mesmo que você não acredite em certificações, o estudo pelo menos é valido.

Espero que esse post possa te ajudar a entender um pouco mais de Web. Naturalmente, o que foi falado aqui não é 1% do que poderia ser dito, mas como sempre, a idéia é que os posts te mostrem as possibilidades, e que você as busque.

Até a próxima!

25. outubro 2010 19:44 by Frederico | Comments (2) | Permalink

Comments

"É isso que todo desenvolvedor Web deve saber: que ele deve conhecer muitas tecnologias!"

Claro que si !
21/08/2011 16:00:00 #
Invocando PageMethods diretamente com JQuery

Invocando PageMethods diretamente com JQuery
31/05/2013 00:50:42 #
Comments are closed

Sobre mim

Minha Imagem

Meu nome é Frederico Batista Emídio, trabalho com desenvolvimento de sistemas profissionalmente a oito anos, porém, já faço sites pessoais a pelo menos dez anos.

Para saber mais clique aqui.

Páginas

Calendário

<<  novembro 2017  >>
seteququsedo
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

Visualizar posts em um Calendário
Sigua @fredemidio

MCP Asp.NET