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

HTML + JavaScript + CSS    

Olá pessoal!

Continuando nossa série de posts introdutório sobre Asp.Net MVC, vamos falar hoje das linguagens básicas a serem utilizadas para o desenvolvimento de sites.

Acho importante abordar esse assunto porque com a facilidade que o WebForm deu ao desenvolvedor de clicar e arrastar controles, e configurar as visibilidades dos controles via Code-Behind, muitos desenvolvedores Asp.Net desconhecem totalmente a razão de ser do HTML, do JavaScript e do CSS.

Muitas pessoas quando precisam editar alguma coisa do código fonte ficam totalmente perdidas, ou se ocorre algum erro no JavaScript, ou a exibição de um controle não fica como o esperado em um determinado navegador: Pronto! “Isso não dá pra fazer”, “Isso é impossível”, “Isso vai levar muito tempo”, etc; É comum ouvir esse tipo de argumento para substituir “não sei como fazer isso”. A credibilidade dos desenvolvedores Asp.Net (e do próprio Asp.Net) caiu muito há alguns anos devido a esse tipo de desenvolvedor preguiçoso, sem o menor interesse de fazer as coisas certas.

É óbvio que o modelo de desenvolvimento do WebForm incentiva esse tipo de pessoa a pensar assim, mas com o Asp.Net MVC isso é diferente! Para fazer uma boa aplicação em Asp.Net MVC, você deve conhecer como a Web funciona, e hoje vamos entender como controlar a experiência do usuário ao navegar no seu site.

No primeiro post, falei de separação de interesses (SoC), mostrando a importância de se separar as coisas de acordo com o seu contexto. No desenvolvimento de um Site também, esse conceito também deve ser respeitado, não no que tange a interação de objetos, mas na responsabilidade de cada linguagem. As três linguagens básicas para desenvolvimento de um site têm uma razão de ser, foram criadas com um objetivo, e esse objetivo deve ser conhecido e respeitado.

A Web, quando foi pensada, não foi pensada apenas para fazer as aplicações serem acessadas de qualquer lugar, através de um navegador, ela não tem a intenção de trazer as possibilidades de uma aplicação desktop para uma aplicação que roda sobre o Browser. A Web também tem a intenção de prover informações, de ter significado, não apenas ser uma aplicação, portanto, quando dizemos que vamos fazer um site, devemos saber quais informações queremos exibir, e como queremos nos expressar com essas informações.

Para saber como expressar o que queremos dizer na web, devemos saber que em um site, o desenvolvimento é dividido em três momentos, em três definições:

  • Definir o que e como dizer (semântica);
  • Definir como usuário deve ver o que queremos dizer (layout)
  • Definir o comportamento do site para exibir o que queremos dizer e como responder ao que o usuário quer ver (behavior)

Entendendo essas três definições, devemos saber qual linguagem utilizar para cada uma delas, então vamos lá!

HyperText Markup Language – HTML (Semântica)

Nos primórdios das Web, o HTML foi criado para o desenvolvedor poder se expressar. As primeiras páginas basicamente eram textos lineares com texto corridos e eventualmente ligações entre uma página e outra, os navegadores liam o HTML e sabiam o que ele queria dizer, e essa foi a intenção do criado do HTML, se expressar.

Para isso, ele criou tags que têm significados claros e que devem ser usadas para aquilo que elas foram criadas, por exemplo:

  • Se você quiser criar uma parágrafo, você utiliza a tag P (Paragraph).
  • Se você quiser criar uma lista não ordenada, você utiliza uma UL (Unordered List)
  • Se você quiser criar uma lista ordenada, você utiliza uma OL (Ordered List)
  • Se você quiser criar itens de uma lista, ordenada ou não, você utiliza uma LI (List Item)
  • Se você quiser exibir dados de forma tabular, você utiliza uma TABLE.

E assim por diante, conhecendo cada tag do HTML, veremos que cada uma tem um significa para cada necessidade de se expressar.

E para que isso serve? Como diz anteriormente, o HTML faz a Web se expressar, um site que se expressa bem, ou seja, que tem boa semântica, pode ser navegado por um deficiente visual.

Por exemplo: Um programa narrador qualquer vai conseguir ler todo o site para uma pessoa que não consiga ler, e ele vai conseguir diferencia cada texto da página, vai conseguir falar para o usuário: “Título – Lista de Receitas”, se ele encontrar um HTML da seguinte forma “<h1>Lista de Receitas</h1>”, pois a tag H1 significa “Header (Título) de nível 1”, ou vai saber falar para o deficiente “Lista: Pudim, Bolo de Cenoura…” se encontrar um HTML assim: ”<ul><li>Pudim</li><li>Bolo de Cenoura</li></ul>”.

Não é só para leitores de texto que o HTML ajuda, para motores de busca também, como o Google. Esses motores de busca processam o HTML e indexa pelo que ele percebe que é importante na página, por exemplo H1, ou listas.

Se você já ouviu falar de Web Semântica e não sabia o que queria dizer, agora já sabe: Web Semântica é usar o HTML de acordo com o que cada TAG quer dizer. Para isso é muito importante conhecermos cada TAG do HTML, e sabermos que elas servem para organizar informação, e não layout.

Estou falando isso, porque há alguns anos atrás ficou na moda um termo chamado Tableless (sem tabelas em inglês), e de onde veio esse termo?

Entendendo Tableless

Quando o desenvolvimento Web começou a se tornar popular, poucas pessoas sabia para que servia o HTML, e começaram a utilizar as tags conforme bem entendiam, e perceberam que era muito fácil criar divisões na página utilizando tabelas (Tag Table). Mas espera aí, TABLE não é para exibir informações tabulares? Sim, então utilizar tabelas para criar divisões é um erro. Algumas pessoas então resolveram disseminar boas práticas do HTML e criaram esse termo, e mostram para o mundo que divisões em páginas, se criavam com tags DIVs.

Div é uma das poucas tags que não têm semântica de informações, serve apenas para criar blocos de códigos dentro de uma página. Deve ser usada após criar toda a semântica da página, iniciando o processo de design, mas apenas pensando em divisões de informações, e não em divisões de layout. O que quero dizer com isso? Quero dizer que se você sabe que uma informação pode não ser seqüência de outra, você pode utilizar um DIV, pois o designer futuramente pode querer dispor essa informação em um lugar diferente, sem fazer a exibição perder o sentido.

O termo Tableless muitas vezes é mal interpretado, pois as pessoas pensam que é proibido utilizar a tag TABLE, mas não é isso, é não utilizar TABLE para criar layout, divisões, dispor informações e isso estar errado, mas se você quiser em algum momento mostrar realmente uma tabela, mostra dados tabulares, você DEVE utilizar uma tag TABLE, pois semanticamente esse é o correto.

Já presenciei absurdos como utilizar infinitas DIVs para criar uma tabela, e isso está redondamente errado. Lembre-se: Tableless é a aplicação de Web Semântica! E uma coisa não pode contradizer outra!

Se você já ouviu falar de WebStandards saiba que nada mais é do que basicamente a aplicação de Web Semântica, no que tange a HTML.

Tentei mostrar basicamente para que serve HTML, caso você pense que vale a pena falar um pouco mais sobre isso, me fale, que posso falar em outro post. É importante saber que devemos conhecer o maior número de TAGs, para sabermos quando e para que usá-las. É interessante visitar o site da W3C para estudar um pouco sobre as tags e seus atributos, para que nossas páginas fiquem sempre mais inteligentes.

Cascading Style Sheet – CSS (Layout)

O CSS é uma linguagem de estilo ou design. É o CSS que define cor, posição e tamanho dos objetos em uma página Web, ela trabalha em cima da estrutura do HTML, portanto, é muito importante que o HTML esteja bem formado para que o layout seja facilmente manipulado. No Asp.Net, técnicas conhecidas como Tema são aplicados utilizando CSS.

Este blog utiliza a engine BlogEngine.Net. Você já deve ter lido vários Blogs que utilizam a mesma engine, porém, com layouts totalmente diversificados. Isso é possivel com a aplicação de CSSs diferentes. O HTML sempre continua o mesmo, porém a disposição das informações na tela é diferente. O HTML é o mesmo porque a informação que se deseja exibir é a mesma, portanto, a semântica é a mesma, para um deficiente visual, a ordem da informação será a mesma, independente do Layout, apenas o estilo (Layout) da informação variará, o que não altera em nada a semântica do site.

Para a utilização do CSS você pode definir sua implementação dentro de uma tag STYLE ou do atribulo style de uma TAG, porém, o mais comum, e mais recomendado, é a utilização em um arquivo separado, onde o mesmo código pode ser utilizado em várias páginas diferentes, além do arquivo individualmente poder ser utilizado a partir do cache do navegador, tornando o carregamento da página muito mais rápido. Utilizando um arquivo externo para programar o estilo da página, você deve referenciar o arquivo através da tag LINK, normalmente colocada dentro da tag HEAD.

Neste post, o objetivo não é mostrar as características a fundo do CSS, como o objetivo desta série de post é te preparar para o Asp.Net MVC, quero deixar claro que o CSS tem o objetivo de definir o estilo, ou design, da página, e toda configuração nesse sentido deve ser controlado pelo CSS.

Sempre que ao desenvolver uma página você sentir a necessidade de fazer a página ficar mais bonita, pense em CSS. Mesmo que você conheça alguma tag ou configuração HTML que resolva o seu problema, evite utilizá-la. Lembre-se, o CSS é o responsável pelo Design e o HTML pela semântica.

Caso você tenha maior interesse em conhecer CSS, poderá visitar também o site da W3C, ou visitar o ótimo site do Moujor, onde você encontrará muitas informações sobre WebStandards e Tableless.

JavaScript – Comportamento

JavaScript foi criada em 1995 pela Netscape. Sua intenção original era realizar validações em formulários e realizar interações com a página. Através do JavaScript é possível mudar informações do HTML, inclusive informações relacionadas com o CSS, o que é conhecido como DHTML.

Devido a essa capacidade de alterar informações do HTML que ao JavaScript é dado a responsabilidade de controlar o comportamento da página.

Como linguagem, o JavaScript tem algumas características:

  • Apensar de inspirada no Java, mas o conceito é bem diferente.
  • É interpretada e não compilada, ou seja, os erros ocorrerão apenas em tempo de excução.
  • Quanto ao tipo:
    • É fracamente tipada, tem o tipo mutável.
    • É dinâmica, ou seja, o tipo de uma variável muda durante a execução da aplicação.
    • É implícita, ou seja, a variável são declaradas sem tipos.

Como o CSS, o javascript pode definido em uma TAG dentro da página, sendo esta a tag SCRIPT, em um atributo de um tag, sendo este qualquer atributo que leve o nome de um evento, como onclick, ou onblur ou em um arquivo externo, também através da TAG SCRIPT, valorizando o atributo SRC com o endereço do arquivo. Essa técnica tem o mesmo benefício de CSS externos à página, ou seja, ganha desempenho com Cache do navegador e pode ser utilizado em várias páginas.

Para estudar JavaScript, um ótimo site seria o W3Schools, onde você poderá entender como funciona cada características da linguagem, desde a objetos à Garbage Collector.

Uma boa página, com boa interação com o usuário, deve sempre fazer bom uso do JavaScript. O Asp.Net utilizada Javascript onde você imaginar, e framework .Net, com Ajaxtook kit vivem a custa disso.

Com a popularização do JavaScript e do conceito Web 2.0, a necessidade de páginas cada vez mais interativas fez sugir diversas bibliotecas baseadas em JavaScript, que facilitam muito a vida de um desenvolvedor Web, que todos deveriam conhecer ao menos uma. Segue uma pequena lista:

Cada biblioteca JavaScript tem sua característica específica e muitas vezes uma finalidade específica, estude cada uma delas e veja qual é a melhor para o seu problema.

Conclusão

Este post teve a intenção de mostrar qual é o objetivo de cada linguagem de Browser da Web. É importante conhecer a divisão delas, para saber como usar. Quanto melhor a utilização dessas três linguagens, maios rápido vai ser o desempenho da sua página e melhor o tempo de desenvolvimento e manutenção.

Sem essas três linguagens a Web não existiria (Internet não é Web, caso não saibam), e o mal uso dela pode tornar a Web insustentável.

Para um bom desenvolvimento Web, e sem dúvida para um bom desenvolvimento em Asp.Net MVC, o conhecimento delas é impresindível.

Dei mais foco ao HTML (apesar de que ainda é pouco), porque é o que as pessoas mais dizem que sabem, sem nunca terem se questionado se sabem mesmo ao menos o conceito, é o que o eu aviso: Estude, aprenda HTML!

Espero que esse post tenha servido para entender um pouco mais como funciona o desenvolvimento de páginas Web, e te ajude a saber o que estudar para começar com Asp.Net MVC.

Abraços e até o próximo.

18. outubro 2010 07:36 by Frederico | Comments (3) | Permalink

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