Artigo no estilo: Curso
Este tema será dividido em duas partes, para que primeiro possamos ter uma
visão clara do que se trata serviços Web com REST junto ao protocolo HTTP e
seus verbos, ou métodos, e na segunda parte abordaremos o ASP.NET Web API,
apresentando os aspectos de sua estrutura e também a construção de um serviço
seguindo os padrões do REST e também mostrando o consumo do serviço através de
uma aplicação WPF.
Tempos atrás, os sistemas desenvolvidos para uma única plataforma, como os grandes sistemas financeiros rodando em mainframes, atendiam às necessidades dos negócios das empresas e supriam a demanda do mercado por consumo de produtos e serviços.
Porém, nos dias de hoje este cenário praticamente está em extinção, o mercado mudou e a tecnologia está evoluindo a passos largos, principalmente com a chegada dos dispositivos móveis como smartphones, tablets e até mesmo televisões, ultrabooks, carros com computador de bordo e relógios sofisticados como os smartwatch.
Esses dispositivos necessitam de acesso às diversas fontes de informações e serviços externos ao aparelho que se encontram em plataformas dos mais variados tipos, desta forma, a Web junto ao protocolo HTTP se tornou o melhor caminho para tal comunicação entre sistemas distribuídos.
Assim sendo, os Web Services utilizando a arquitetura SOA junto ao protocolo SOAP (BOX 1) tiveram seu auge e contribuição para tal integração entre sistemas, porém, com passar do tempo essa se tornou uma solução bastante complexa e com o custo bastante elevado para a implementação em sistemas de plataformas distintas, principalmente em dispositivos móveis.
Além disso, essa alternativa levava à necessidade por um melhor desempenho, requerendo certo poder de hardware tanto no servidor que expõe o serviço quanto no dispositivo que o consome.
Diante das dificuldades observadas nesse cenário, entendeu-se a necessidade por uma solução mais leve e de simples implementação para expor serviços via Web. Surgiu assim uma nova forma de disponibilizar esses serviços para possibilitar a comunicação mais facilmente entre diversos dispositivos e plataformas através da Web, utilizando o protocolo HTTP: o modelo REST (REpresentation State Transfer).
SOA (Service Oriented Architecture) ou em tradução livre para o português, Arquitetura Orientada a Serviços, é um estilo de arquitetura para desenvolvimento de software cujo princípio fundamental define que as funcionalidades implementadas devem ser disponibilizadas para as aplicações clientes na forma de serviços.
O serviço deve fornecer contratos ou interfaces que podem ser lidos pelo cliente para conhecer previamente a estrutura das mensagens que serão trocadas com o servidor.
SOAP (Simple Object Access Protocol), que em tradução livre para o português seria Protocolo Simples de Acesso a Objetos, é um protocolo para troca de informações através de mensagens estruturadas no formato XML entres plataformas e sistemas distribuídos.
A Web e protocolo HTTP
Para iniciar o estudo sobre o estilo arquitetural REST e sua estrutura, nada melhor do que conhecemos um pouco sobre a Web e a estrutura do protocolo HTTP, pois quem para necessita conhecer a fundo o REST é de fundamental importância que tenha certo conhecimento sobre o funcionamento da WWW e principalmente do protocolo HTTP, sua estrutura, seu funcionamento e seus verbos para requisições.
Um pouco da história da WWW
A WWW (World Wide Web) ou simplesmente Web, que em tradução livre seria rede mundial de computadores, foi idealizada por Tim Berners-Lee, que tinha na época o objetivo de tornar mais fácil a exposição de documentos entre seus colegas de trabalho.
Porém, o mesmo fez uma proposta formal por volta de 1990 para tornar a Web acessível via internet, onde o objetivo era ter um servidor que disponibilizava o acesso a um sistema de documentos em hipermídia que pudesse ser acessado por meio de um software conhecido como navegador, nossos tão famosos browsers.
Assim, por meio de um browser o usuário poderia facilmente acessar um documento de hipermídia que era disponibilizado em um servidor executado na internet. Os documentos poderiam ser disponibilizados em vários formatos como textos, vídeos, sons, hipertextos, figuras e poderiam ser facilmente vistos por meio de páginas Web que são renderizadas em um browser, que por sua vez interpretava uma linguagem de marcação de hipertexto, a HTML (HyperText Markup Language), a linguagem que estrutura toda a visualização dos elementos de uma página Web.
Podemos definir um conjunto de páginas Web como sendo um website, podendo haver outras denominações mais específicas como portal, de acordo com tipo e finalidade do website que se desenvolver.
Conhecendo o protocolo HTTP
O HTTP (Hypertext Transfer Protocol, ou Protocolo de Transferência de Hipertexto) surgiu do trabalho e pesquisa de praticamente três grandes personalidades da Web, Tim Berners-Lee, o criador da Web, Roy Fielding, criador do REST e Henrik Frystyk Nielsen, um dos responsáveis pela padronização do SOAP com XML.
O protocolo HTTP é o principal meio de troca de mensagens de hipermídia para a Web no paradigma cliente servidor (requisição e resposta), pois seu objetivo é prover a comunicação entre uma aplicação cliente (como o browser) e uma aplicação servidor (hospedagem de websites e serviços), possibilitando ao cliente realizar requisições (request) ao servidor e o este retornar uma resposta (response) ao cliente.
Esta resposta pode ser formada apenas por código de estado do conteúdo solicitado via URI (BOX 2) informando o sucesso, fracasso ou falha na requisição, ou uma resposta contendo uma mensagem a ser exibida pelo browser, que na maioria das vezes é no formato HTML.
URI (Uniform Resource Identifier) é uma cadeia de caracteres compacta usada para identificar ou denominar um recurso na internet. O principal propósito desta identificação é permitir a interação com representações do recurso por intermédio de uma rede, tipicamente a internet, usando protocolos específicos com HTTP.
É importante frisar que para estabelecer uma comunicação entre um computador cliente e o servidor remoto é preciso estabelecer uma conexão via protocolo TCP/IP (BOX 3) e utilizar o protocolo HTTP para realizar as requisições e respostas entre o cliente e o servidor. Observe a Figura 1, que mostra um exemplo de uma requisição e resposta entre cliente e servidor utilizando o protocolo HTTP.
O TCP/IP é um conjunto de protocolos de comunicação entre computadores de uma rede. TCP significa Transmission Control Protocol - Protocolo de Controle de Transmissão, e o IP significa Internet Protocol - Protocolo de Internet.
O conjunto de protocolos pode ser visto como um modelo de camadas (Modelo OSI), onde cada camada é responsável por um grupo de tarefas, fornecendo um conjunto de serviços bem definidos para o protocolo da camada superior. As camadas mais altas estão logicamente mais perto do usuário (chamada camada de aplicação) e lidam com dados mais abstratos, confiando em protocolos de camadas mais baixas para tarefas de menor nível de abstração.
Tendo em vista que o protocolo HTTP é a base para troca de conteúdo hipermídia na Web, é importante saber que o mesmo reside na camada de aplicação do Modelo OSI, que divide a rede de computadores em sete camadas. Não entraremos em maiores detalhes sobre este modelo, pois isso fugiria do escopo deste artigo.
Figura 1. Modelo requisição e resposta cliente servidor com protocolo HTTP 1.1.
O acesso a páginas na Web é realizado por meio do protocolo HTTP e pode ser feito normalmente via browser, onde o usuário informa na barra de endereços uma URL (Universal Resource Locator ou Localizador Universal de Recurso) do site.
Esta comunicação é realizada na maioria das vezes utilizando a porta 80 e trocando mensagens no formado HTML, seja uma simples requisição de uma página web ou até mesmo o envio de um formulário HTML utilizando o tag <form> com o atributo action que determina qual verbo (método) do protocolo HTTP que se deseja usar.
Mais à frente neste artigo você irá conhecer em detalhes os verbos do HTTP, porém é importante saber que os verbos mais utilizados são o GET e POST.
Mensagens HTTP 1.1
Conforme ilustrado na Figura 1, a comunicação entre o cliente e servidor é realizada através de requisições feitas pelo cliente e respostas de retorno enviadas ao cliente pelo servidor, desta forma são trocadas inúmeras mensagens entre o cliente e o servidor com o protocolo HTTP.
As mensagens de envio e respostas são genéricas, ou seja, seguem alguns padrões que foram definidos em um documento especifico descrito e definido pela RFC (BOX 4).
O Request for Comments (RFC) é um documento de publicação da Internet Engineering Task Force (IETF) e da sociedade da internet formada pelos principais órgãos de estabelecimento de normas técnicas e padrões de desenvolvimento técnico para a Internet e seus protocolos.
São várias publicações em forma de documentos numerados que cobrem muitos aspectos da rede mundial de computadores, incluindo protocolos, procedimentos, programas, normas e conceitos, bem como notas de reuniões, e opiniões de autoria de engenheiros e cientistas da computação na forma de um memorando descrevendo os métodos, comportamentos, pesquisa ou inovações aplicáveis ao funcionamento da internet e sistemas conectados à internet, veja mais detalhes sobre RFC na seção Links no final do artigo.
As mensagens de requisição e resposta do protocolo HTTP devem conter alguns elementos que foram definidos na RFC 2616, ou seja, a mensagem deve ter um cabeçalho, um corpo e iniciar com uma linha em branco seguida por metadados (informações sobre a estrutura da mensagem) que definem algumas características pertinentes à mensagem tanto para uso pelo servidor quanto pelo browser do cliente. Logo após vem o corpo da mensagem que é opcional, sendo usado de acordo com o tipo de mensagem trocada entre o cliente e o servidor.
Quando o cliente realiza uma requisição ao servidor, é enviada uma mensagem que contém um cabeçalho também conhecido como header. No cabeçalho da mensagem é informado o tipo de método do protocolo HTTP, uma URI que aponta para um recurso no servidor, a versão do protocolo HTTP, o host que está sendo utilizado, o MIME (Multipurpose Internet Mail Extensions) que se destina aos formatos dos tipos de dados a serem trocados pela internet e outras informações sobre a requisição e dados do cliente, como o agente o solicitante (geralmente o browser).
Seguindo o cabeçalho, é posto mais uma linha em branco e depois informado o corpo da mensagem, que pode conter vários dados inclusive informações informadas pelo usuário como, o preenchimento de um formulário HTML.
Cabeçalho de requisição
Para entender melhor a composição do cabeçalho de uma requisição por parte do cliente a um servidor web, vejamos na Listagem 1 um exemplo de uma requisição realizada via browser a uma página disponível na internet com retorno de dados no formato HTML.
Listagem 1. Requisição HTTP 1.1
01
02 GET / HTTP/1.1
03 Accept: text/html
04 Accept-Language: pt-BR
05 User-Agent: Chrome/39.0.2171.95
06 Host: www.devmedia.com.br
07
08 Aqui ficaria o corpo da mensagem se necessárioAnalisando essa listagem que apresenta uma requisição real ao portal DevMedia, podemos destacar os seguintes pontos descritos a seguir a respeito das “metainformações” que compõem esta mensagem:
1. Note que as linhas 01 e 07 estão em branco, isso porque conforme a RFC 2616 a requisição deve ter primeira uma linha em branco e outra separando as informações do cabeçalho do corpo da mensagem.
2. A linha 02 segue a sintaxe: método da requisição HTTP, URI e versão do protocolo HTTP. Assim sendo, temos o verbo GET, que solicita a exibição de conteúdo, a URI que neste caso não é informada, pois se trata de um recurso especifico (apenas a página Default da DevMedia) e por fim a versão do HTTP, que neste caso é a 1.1.
3. Logo na linha 03 é informado ao servidor que tipo de dado é esperado como retorno, neste caso é informado text/html através do Accept, pois é esperada uma página no formato HTML para que o browser possa renderizar e exibir para o usuário a página conforme estrutura do HTML, CSS, scripts e outros links indexados à página apontando para URIs de outros recursos.
4. Na linha 04 é informado o idioma no qual se deseja receber os dados do servidor, que no exemplo foi definido como português do Brasil.
5. Na linha 05 temos a informação do agente que realizou a requisição. ...
