Asp Et Web Api

13/11/2015 ASP.
NET Web API – Parte 1
Buscar
comentários favorito (10) marcar como lido para impressão anotar
.net Magazine 121 Índice
ASP.NET Web API – Parte 1

Veremos neste artigo os principais conceitos
relacionados ao protocolo HTTP e ao modelo REST,
importantes para a construção de serviços web e que
são base para o entendimento e plena utilização do
ASP.NET Web API.

0 0 Curtir 0
Gostei (2) (1)
Demais posts desta série:
ASP.NET Web API – Parte 2
http://www.devmedia.com.br/aspnetwebapiparte1/32158 1/31
13/11/2015 ASP.NET Web API – Parte 1
Artigo no estilo Curso
Fique por dentro
Este artigo é útil para desenvolvedores de uma forma geral e pessoas envolvidas
com o desenvolvimento de sistemas distribuídos, integração de sistemas e web
services que desejam conhecer ou aprimorar o conhecimento sobre o estilo
arquitetural REST, com uso do ASP.NET Web API que está embutido na estrutura
do ASP.NET MVC.
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, entendeuse 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).
BOX 1. SOA e SOAP
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 BernersLee, 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 BernersLee, 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.
BOX2. URI
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.
BOX 3. TCP/IP
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).
BOX 4. RFC (Request for Comments)
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ário
Analisando 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. Neste caso foi
via browser com Google Chrome.
6. Em seguida, na linha 06 temos o host. Neste caso temos o domínio, que é o nome
disponível na internet para facilitar a compreensão do endereço do website. Durante o
processo de requisição este nome será convertido em um número de IP através de um
servidor de DNS (Domain Name System).
7. Por fim, na linha 08 temos o corpo da mensagem, que é opcional e neste caso não
foi preciso informar. Porém, geralmente o corpo é utilizado para passar certo volume de
dados ao servidor via método POST, em situações onde desejamos enviar informações
ao servidor ao invés de apenas recebêlas.
É importante ainda observar que o cabeçalho é formado por uma espécie de dicionário
de dados contendo pares de chave e valor para representar determinadas
configurações e restrições durante a troca de mensagens entre o cliente e o servidor
via protocolo HTTP.
Mensagem de resposta do servidor
Toda requisição que um servidor na Web recebe é processada realizando a leitura dos
dados e informações do cabeçalho e corpo da mensagem da requisição. Em seguida
ele envia uma resposta ao cliente contendo uma linha com versão do protocolo HTTP,
código de status da requisição, metainformações de cabeçalho, o corpo da resposta,
que poderia ser uma página HTML a ser visualizada pelo cliente solicitante, e por fim
deve encerrar a conexão estabelecida.
Na Listagem 2 é apresentado um exemplo de uma mensagem de resposta pelo
servidor que deve ser renderizada pelo browser do cliente. Veja os detalhes do retorno
a seguir:
1. Como padrão, temos duas linhas em branco: a primeira e a de número cinco, que
separa o cabeçalho do corpo da mensagem.
2. Logo na linha 02 temos a versão do HTTP seguido pelo código de status do retorno
e sua descrição. Neste caso uma requisição foi bem sucedida e o status é OK (código
200).
3. Na linha 03 temos o ContentType seguido pelo seu valor, que neste caso informa
que os dados retornados no corpo da mensagem estão no formato HTML. É importante
destacar aqui que o ContentType também é conhecido como Media Type, que define
o tipo de dados aceito na troca de mensagens.
4. Na linha 04 temos o ContentLength com a quantidade de caracteres presentes no
corpo de mensagem.
5. Por fim, da linha 06 até a linha 13 temos o retorno do código HTML a ser
renderizado pelo browser do usuário. Note que se trata de uma página HTML
completa, contendo título, corpo e que poderia conter ainda outros elementos como
scripts e links.
Listagem 2. Resposta servidor HTTP 1.1
01
02 HTTP/1.1 200 OK
03 Content‐Type: text/html
04 Content‐Length: 103
05
06 <html>
07 <head>
08 <title>Portal DEVMEDIA</title>
09 </head>
10 <body>
11 <p>Mensagem de retorno do servidor.</p>
12 </body>
13 </html>
Verbos do protocolo HTTP 1.1

O protocolo HTTP possui vários métodos, também conhecidos como verbos. Com
estes métodos é possível realizar diferentes tipos de requisições ao servidor, sendo
cada uma com um propósito de acesso, inclusão, modificação e exclusão de recursos
no servidor.
Até aqui falamos rapidamente sobre dois métodos mais utilizados: o GET e POST,
porém foram apresentados apenas exemplos de requisições com método GET. Nesta
sessão você irá conhecer os métodos do protocolo HTTP e saberá quando usar cada
em seus projetos, é importante destacar que é fundamental conhecer estes métodos
pois serviços baseados em REST, como o ASP.NET Web API utilizam maior parte
deles e é preciso saber qual utilizar para cada ação a ser realizada na sua aplicação.
Na versão 1.1 do protocolo HTTP são definidos oficialmente nove métodos, que são
descritos a seguir.
GET
Requisições utilizando o verbo GET podem ser realizadas a um servidor de páginas
web ou serviço e tem como objetivo obter uma representação do recurso através de
um media type, como uma representação de uma página com HTML ou uma listagem
de clientes no formato XML.
É importante destacar que requisições GET são apenas solicitações de recursos
através de uma URI e não deve ser utilizado para criar, alterar ou excluir algum
recurso.
Outro ponto importante sobre requisições GET é a possibilidade de passar parâmetros
pela URL na forma de pares de chave e valor. Observe a Listagem 3, que apresenta a
solicitação de um recurso no servidor para listar a informação de um determinado
cliente, onde seu código é passado pela URL de uma requisição com verbo GET. Em
seguida, a Listagem 4 mostra a reposta do servidor com a representação do cliente
solicitado no formato XML.
Listagem 3. Requisição GET com parâmetro
01
02 GET /localhost:8080/index/?codigo_cliente=2747 HTTP/1.1
06 Host: localhost:8080
Listagem 4. Resposta solicitação via GET com retorno em XML
01
02 HTTP/1.1 200 OK
03 Content‐Type: text/xml
05
06 <cliente id="2747">
07 <nome>Madson Aguiar Rodrigues</nome>
08 <endereco>Rua Tabeliao Antonio Almeida</endereco>
09 <bairro>Centro</bairro>
10 <cidade>Sobral</cidade>
11 <estado>Ceara</estado>
12 </cliente>
POST
O verbo POST deve ser utilizado quando se deseja enviar certo volume de dados ao
servidor para processamento. Entenda então que seu uso se destina a criar um novo
recurso no servidor. Um exemplo disso seria o envio de formulário HTML que poderia
conter informações de cadastro de um novo fornecedor para ser processado pelo
servidor e assim inserir os dados do fornecedor em uma base de dados.
Sendo assim, o formulário presente na Listagem 5 no formato HTML pode representar
a submissão dos dados do fornecedor ao servidor via método POST, gerando uma
requisição como a que é apresentada na Listagem 6.
Diferentemente do método GET que envia dados ao servidor pela própria URL, que
tem uma quantidade de caracteres limite e também faz com que os dados fiquem
expostos ao usuário na URL, o método POST envia as informações ao servidor através
do corpo da mensagem, que neste caso não tem limite e as informações enviadas não
ficam expostas facilmente na URL.
Isso gera certa segurança quanto à ocultação dos dados para o usuário final, porém,
nada impede que pessoas mal intencionadas consigam capturar a informação
transmitida pela rede com uso de alguns softwares como o Fiddler.
Assim sendo, quando temos um projeto que precise de certo grau de segurança na
transmissão dos dados, o ideal é utilizar o protocolo HTTPS para criptografar os dados
durante as requisições e repostas entre o cliente e o servidor, assim as informações
trafegarão em um formato inicialmente desconhecido para aqueles que não possuem
conhecimento sobre o método e chaves de encriptação utilizados.
Listagem 5. Formulário HTML cadastro de fornecedores
01 <html>
02 <head>
03 <title>Cadastro de fornecedores</title>
04 <meta charset="UTF‐8">
05 </head>
06 <body>
07 <form action="/fornecedor" method="POST">
08 <h1>CADASTRO DE FORNECEDORES</h1> <br/>
09 <label for="nome_empresa">Nome: </label> <br/>
10 <input type="text" name="nome_empresa"> <br/>
11 <label for="cnpj">CNPJ: </label> <br/>
12 <input type="text" name="cnpj"> <br/>
13 <label for="endereco">Endereço: </label> <br/>
14 <input type="text" name="endereco"> <br/>
15 <label for="bairro">Bairro: </label> <br/>
16 <input type="text" name="bairro"> <br/>
17 <label for="cidade">Cidade: </label> <br/>
18 <input type="text" name="cidade"> <br/> <br/>
19 <input type="submit" value="Enviar">
20 </form>
21 </body>
22 </html>
Observando essa listagem é importante destacar alguns trechos de código:
· Na linha 07 temos a definição da tag <form> para possibilitar o envio do formulário ao
servidor e nela foram definidos dois atributos importantes: o action que se deve
informar a URI do caminho da página ou serviço que irá capturar e processar as
informações do formulário, e logo após temos a definição do atributo method, que é
responsável pela definição de como será enviada a requisição ao servidor.
Neste caso usamos o POST, pois queremos enviar certo volume de dados ao servidor
pelo corpo da mensagem e também porque o verbo POST se destina a criar novos
recursos, e aqui seria um cadastro para um novo fornecedor.
· Perceba que da linha 10 até a linha 18 temos a definição dos campos do tipo input
que são responsáveis por recuperar e armazenar os dados informados pelo usuário no
momento do preenchimento do formulário.
Assim sendo, temos o atributo name do input que será usado como chave para que se
possa recuperar dos dados do fornecedor durante o processamento no servidor. Aqui
novamente é criada uma espécie de dicionário de dados formado pelo nome do input e
o valor informado pelo usuário.
· Por fim, na linha 19 temos a definição de um input do tipo submit que responsável por
submeter a página ao servidor de acordo com tipo de verbo do protocolo HTTP
informado no atributo method da tag HTML do form.
Listagem 6. Requisição via POST gerada pelo form da Listagem 5
01
02 POST /fornecedor HTTP/1.1
08 Content‐Type: application/x‐www‐form‐urlencoded
09
10 nome_empresa=Madson+empsoft&cnpj=1234567891011&endereco=Rua+Tabeliao+Antonio+Almeida&ba
Analisando essa listagem que representa a requisição enviada ao servidor para
processamento do formulário da Listagem 5 para cadastro de novo fornecedor,
podemos fazer algumas observações:
· Como de costume temos a primeira linha vazia e logo na linha 02 o tipo de verbo do
HTTP usado na requisição, neste caso o POST.
· Na linha 07 temos o tamanho da mensagem que estamos enviando contendo a
quantidade de caracteres.
· Na linha 08 é definido o formato em que formulário será enviado, ou seja, com dados
codificados.
· E por fim na linha 10 temos os dados que foram informados pelo usuário nos campos
input. Perceba que existe certa sintaxe para separar os dados: primeiramente é
informado o nome do input tipo text seguido pelo caractere = e logo após o valor
preenchido pelo usuário.
Seguindo esta lógica o restante dos inputs e seus valores são separados pelo &
comercial até compor totalmente a quantidade de dados a ser enviada ao servidor de
acordo com os componentes infirmados via tag HTML.
PUT
Você deve utilizar o método PUT quando desejar alterar certo recurso no servidor
através da URI do mesmo, desta forma irá lhe possibilitar realizar uma manutenção no
recurso, ou seja, uma atualização no mesmo ao ainda criar um novo recurso, caso este
ainda não exista no momento da realização da requisição.
DELETE
Como o próprio nome o descreve, o método DELETE deve ser utilizado com intuito
excluir um recurso do servidor, lembrando que deve ser informado uma URI referente
ao recurso que deve ser excluído.
Além dos métodos GET, POST, PUT e DELETE descritos anteriormente ainda existem
outros cinco métodos que são OPTIONS, HEAD, TRACE, CONNECT e PATCH no
protocolo HTTP. Você pode obter mais detalhes no RFC 2616 que define o protocolo
HTTP 1.1 (veja a seção Links).
Idempotência e segurança dos métodos do

protocolo HTTP
Cada um dos métodos HTTP tem uma particularidade especifica para determinada
aplicação, sendo assim é importante saber quando usálos e qual usar em determinada
operação. Pesando nisso é importante entender duas características sobre estes
métodos: a idempotência e a segurança deles.
Idempotência
Existe um conceito bastante importante no protocolo HTTP que é a idempotência de
métodos, seu entendimento será de grande ajuda na construção de serviços baseados
em REST. A idempotência de métodos do protocolo HTTP ocorre quando são
realizadas várias requisições ao servidor utilizando um verbo especifico do protocolo
para a execução de uma determinada operação.
Assim sendo, o método é considerado idemponente se após várias execuções da
operação com o mesmo método o valor do resultado da executarão seja o mesmo da
primeira execução.
Um exemplo da idempotência seria a atualização de registro em base de dados através
de um serviço baseado no REST que disponibiliza o recurso através de uma URI para
atualização através de requisições com verbo PUT. Desta forma poderíamos usar o
método PUT do HTTP para fazer a requisição ao serviço e assim informar os dados a
serem atualizados.
Desta maneira o serviço utilizando o método PUT sempre deve se comportar da
mesma maneira, embora o procedimento seja realizado várias vezes consecutivas,
entenda que quando dizemos que ele que deve se comportar da mesma maneira,
estamos nos referindo ao fato de obtermos o mesmo resultado da execução da
operação todas as vezes.
Segurança
Os métodos do protocolo HTTP são considerados seguros se requisições com um
método especifico não causarem nenhuma alteração ou exclusão em algum recurso
disponível no servidor. Desta maneira, se realizarmos uma comparação de alguns
métodos do protocolo HTTP com as operações CRUD em banco de dados, logo
podemos notar que, conforme demonstra a Tabela 1, o único método deste tipo nesta
comparação seria o método GET em comparação com a operação de SELECT.
Segurança métodos HTTP X Operações CRUD
Método HTTP Operações CRUD Seguro?
POST CREATE NÃO
GET READ SIM
PUT UPDATE NÃO
DELETE DELETE NÃO
Tabela 1. Segurança método HTTP X Operações CRUD
Confira na Tabela 2 uma listagem mais completa dos métodos do protocolo HTTP e
sua classificação quanto à idempotência e segurança.
Idempotência e segurança dos métodos do HTTP
Método HTTP Idempotente Segurança
POST NÃO NÃO
GET SIM SIM
PUT SIM NÃO
DELETE SIM NÃO
OPTIONS SIM SIM
HEAD SIM SIM
PATCH SIM NÃO
Tabela 2. Segurança método HTTP X Operações CRUD
Introdução ao REST
Representational State Transfer ou simplesmente REST, que em português seria
Transferência de Estado Representacional, é considerado um estilo arquitetural para o
desenvolvimento de sistemas de hipermídia distribuídos.
O REST é um estilo híbrido derivado de vários estilos arquitetônicos baseados em
rede, mas tem a sua idealização e pilar na implementação de serviços Web em cima
da arquitetura do próprio protocolo HTTP juntamente aos seus métodos.
O termo REST teve início nos anos 2000 na dissertação do coautor do protocolo HTTP,
Dr. Roy Thomas Fielding, para obtenção do título PhD na universidade UC Irvine na
Califórnia. Sua dissertação tinha como tema Architectural Styles and the Design of
Networkbased Software Architectures (Estilos arquitetônicos e o projeto de
arquiteturas de software baseado em rede).
O REST é apresentado na dissertação de Roy Fielding no capítulo de número cinco,
onde o mesmo faz uma definição geral sobre o que seria o estilo arquitetural REST.
Você pode ler na integra a dissertação de Roy Fielding conforme link disponível na
seção Links deste artigo.
A partir deste ponto iremos iniciar um estudo sobre o estilo arquitetural REST, seus
princípios para a engenharia de software orientada ao REST, as limitações e restrições
do modelo.
Arquitetura Cliente Servidor
O REST é composto por um mescla de arquiteturas de rede, padrões e mais algumas
inclusões feitas por Roy Fielding ao estilo arquitetônico REST. Assim sendo, uma das
as primeiras restrições adicionadas a este estilo híbrido é a arquitetura Cliente
Servidor, que possibilita a troca de conteúdo hipermídia através de requisições e
reposta.
Aqui também é realizada uma divisão em camadas que separa a estrutura de interface
do usuário dos dados e recursos propriamente dito.
Segundo Roy Fielding, podese melhorar a portabilidade da interface do usuário
através de múltiplas plataformas e melhorar a escalabilidade, simplificando os
componentes do servidor, pois esta separação permite que os componentes possam
evoluir de forma independente de acordo com a necessidade do negócio.
O princípio da separação de interesses por parte da arquitetura cliente servidor,
juntamente ao REST, propicia uma separação adequada das funcionalidades do
serviço e simplifica os componentes de software do lado do servidor a fim de melhorar
a escalabilidade. Para melhor entendimento veja a Figura 2.
Figura 2. Separação e interesses e responsabilidade ClienteServidor.
Quando estivermos exemplificando a implementação do REST utilizando a ASP.NET
Web API, você verá e entenderá que o uso de padrões de projeto como MVC facilita a
implementação de serviços baseados em REST e modulariza as responsabilidades do
serviço tornando o mesmo mais manutenível.
Stateless
O REST utiliza da arquitetura clienteservidor e parte de suas restrições, porém
devemos observar o ClientStatelessServer (CSS), ou seja, no REST o servidor não
pode armazenar nenhum tipo de estado entre as requisições e respostas para o
cliente, de tal forma que cada pedido do cliente para servidor deve conter todas as
informações necessárias para compreender a mensagem referente à requisição.
Com isso a aplicação cliente não pode tirar vantagem de qualquer contexto de
armazenamento de estado no lado do servidor.
Então o Stateless do REST define que qualquer tipo estado de sessão deve ser
mantido inteiramente no lado do cliente, conforme ilustra a Figura 3. Assim sendo,
estas restrições induzem às propriedades de visibilidade, confiabilidade e
escalabilidade conforme descrição a seguir.
Visibilidade: a visibilidade é melhorada porque o servidor já recebe todas as
informações necessárias para processar a requisição, não tendo nenhum trabalho
extra de recuperar ou gerenciador estados entre seus clientes e suas requisições.
Confiabilidade: a Confiabilidade é melhorada, pois a gestão de estado é de
responsabilidade do cliente, o que diminui mais uma responsabilidade por parte do
servidor e facilita a tarefa do mesmo na recuperação de possíveis falhas.

Escalabilidade: a escalabilidade é melhorada devido ao fato de o servidor não ter
que armazenar estado de sessão entre as solicitações do cliente, permitindo que o ele
libere recursos rapidamente e também por simplificar bastante a implementação, pelo
fato do servidor não ter que gerenciar o uso de recursos entre solicitações.
Figura 3. ClientStatelessServer (CSS)
Cache
O uso de cache é outro ponto importante adicionado ao estilo REST, o mesmo tem o
objetivo de melhorar a eficiência da rede diminuindo a quantidade de requisições e
respostas ao servidor. Desta forma teríamos informações mantidas no lado do cliente
através de cache que podem ser facilmente reutilizadas posteriormente durante a troca
de mensagens com o servidor.
As restrições de cache formam o que chamamos de ClientCacheStatelessServer que
pode ser mais bem compreendida pela Figura 4.
Figura 4. ClientCacheStatelessServer
Segundo Roy Fielding, a vantagem da utilização de cache juntamente ao REST é que
eles têm o potencial de eliminar parcialmente ou completamente algumas interações
com o servidor, melhorar a eficiência, escalabilidade e desempenho por parte do
expositor e utilizador do serviço durante as interações.
É importante salientar que o cache pode diminuir a confiabilidade se os dados se
tornarem obsoletos e diferirem significativamente a partir de novas requisições
diretamente ao servidor.
Então esta implementação de cache no cliente deve ser bem planejada para não
comprometer o funcionamento da aplicação que utiliza serviços com base no REST,
evitando assim perda de confiabilidade dos dados no cache do cliente.
Interface uniforme
Os serviços baseados na arquitetura REST utilizam uma interface uniforme para
comunicação entre o cliente e o servidor, esta interface uniforme se dá pela exposição
de recursos através da identificação do mesmo, também é importante frisar que o
recurso deve ser autodescritivo por uso de substantivos.
É importante destacar que a interface uniforme do REST expõe os recursos através do
apontamento utilizando URL’s, sendo que para acesso a estes recursos devemos usar
os verbos do protocolo HTTP.
Como exemplo temos os principais métodos já descritos anteriormente no estudo sobre
HTTP que são os verbos GET, POST, PUT e DELETE. Com uso destes métodos
podemos facilmente realizar operações como realizar uma consulta a um recurso, criar
um recurso, atualizar e excluir e um recurso no servidor.
Estes conceitos ficarão bem mais claros quando estivermos implementando eles na
prática utilizando a Web API, que faz uso intenso destes métodos nas actions de seus
controllers.
A interface uniforme está ligada diretamente com o protocolo HTTP e seus verbos, os
serviços REST por sua vez expõem recursos através de URL’s amigáveis e auto
descritiva por substantivos, porém, tome cuidado quanto à exposição de recursos para
serem acessados pelos verbos não seguros do protocolo HTTP.
Para melhor compreensão da interface uniforme veja na Listagem 7 um exemplo de
como deve ser uma requisição para criar um novo recurso, neste caso adicionar um
produto utilizando o verbo POST do protocolo HTTP. Logo depois, na Listagem 8, veja
como seria a resposta do produto adicionado utilizando a representação do mesmo no
formato JSON.
Listagem 7. Requisição via POST para adicionar um novo produto
01
02 POST http://localhost:8080/produtos HTTP/1.1
04 Content‐Type: application/json
07
08 {"Nome": "Produto 1", "Descricao": "produto teste", "Valor": "10.00"}
Listagem 8. Resposta do servidor referente ao pedido para adicionar um novo produto
01
02 HTTP/1.1 201 Created
03 Content‐Type: application/json
04 Location: http://localhost:8080/produtos/47
06
07 {"ID": "47","Nome": "Produto 1", "Descricao": "produto teste", "Valor": "10.00"}
Analisando a primeira listagem, perceba as características referentes ao uso da
interface uniforme logo na linha 02, pois estamos utilizando o verbo POST para
adicionar um recurso seguido pela URI que informa para onde a requisição deverá ser
encaminhada.
Após isso, temos outro ponto importante na linha 04 onde informamos o tipo de
representação do produto, neste caso o JSON, pois na linha 07 temos a representação
do produto a ser adicionado no formato JSON.
Já nessa segunda listagem, o primeiro ponto importante está logo na linha 02, que
informa o código 201 indicando que o produto foi acionado com sucesso. Na linha 03
temos o tipo de representação do produto, na linha 04 temos uma URI apontando onde
o novo produto adicionado está disponível para consulta.
Aqui podemos usar o verbo GET para consultar e recuperar os dados deste produto.
Por fim, na linha 07 temos a representação propriamente dita do novo produto
adicionado, esta representação está no formato JSON com um novo atributo chamado
ID, que tem como valor o código do produto, assim podemos consultar facilmente o
mesmo conforme URI informada na linha 04.
A compreensão dos conceitos relacionados ao protocolo HTTP e ao modelo REST é
fundamental para que possamos desenvolver serviços para e expor dados e
funcionalidades de uma forma padronizada e que possam ser facilmente consumidas
pelas aplicações clientes.
Na próxima parte desta série veremos como a ASP.NET Web API faz uso desses
conceitos para permitir o desenvolvimento de serviços web que podem ser consumidos
tanto por um browser, como por qualquer outra aplicação cliente que seja capaz de
requisitar as informações desejadas através de uma URI.
Links
Request for Comments (RFC)
http://www.ietf.org/rfc.html
RFC 2616 Protocolo HTTP 1.1
http://tools.ietf.org/html/rfc2616
Dissertação Dr. Roy Fielding
https://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf

Madson Aguiar Rodrigues
Formação acadêmica em Análise e Desenvolvimento de Sistemas pela UNOPAR, pósgraduação em
Engenharia de Sistemas pela ESAB e especialista em Tecnologias para aplicações Web pela UNOPAR.
Trabalha com desenvolvimento de software há [...]
Publicado em 2015
O que você achou deste post?
Gostei (2) (1)
+ Mais conteúdo sobre .net
Não há comentários Postar dúvida / Comentário
Meus comentarios
Publicidade
Mais posts
Artigo
Explorando os recursos da plataforma .NET
Artigo
Nancy Framework: Serviços HTTP em .NET
Artigo
Desenvolvimento multiplataforma com Xamarin – Parte 1
Artigo
Integrando aplicações com Web API – Parte 3
Artigo
ASP.NET MVC: Criando um fórum de discussão com

Bootstrap
Artigo
Spring.NET: Como reduzir a abstração em sistemas
Listar mais conteúdo
Anuncie | Loja | Publique | Assine | Fale conosco
DevMedia
Curtiu 81 mil curtidas
Você curtiu isso
Hospedagem web por Porta 80 Web Hosting

Asp Et Web Api

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Asp Et Web Api

Uploaded by

Copyright:

Available Formats

13/11/2015 ASP.

comentários favorito (10) marcar como lido para impressão anotar

ASP.NET Web API – Parte 1

A Web e protocolo HTTP

Um pouco da história da WWW

Conhecendo o protocolo HTTP

Mensagens HTTP 1.1

Mensagem de resposta do servidor

Verbos do protocolo HTTP 1.1

Idempotência e segurança dos métodos do

Método HTTP Operações CRUD Seguro?

POST CREATE NÃO

GET READ SIM

PUT UPDATE NÃO

DELETE DELETE NÃO

Método HTTP Idempotente Segurança

POST NÃO NÃO

GET SIM SIM

PUT SIM NÃO

DELETE SIM NÃO

OPTIONS SIM SIM

HEAD SIM SIM

PATCH SIM NÃO

Arquitetura Cliente Servidor

Explorando os recursos da plataforma .NET

Nancy Framework: Serviços HTTP em .NET

Desenvolvimento multiplataforma com Xamarin – Parte 1

Integrando aplicações com Web API – Parte 3

ASP.NET MVC: Criando um fórum de discussão com

Spring.NET: Como reduzir a abstração em sistemas

Listar mais conteúdo

Anuncie | Loja | Publique | Assine | Fale conosco

You might also like