Webservices RESTful

Prévia do material em texto

DESENVOLVIMENTO 
PARA DISPOSITIVOS 
MÓVEIS
Fabricio Machado da Silva
Webservices RESTful
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Analisar o uso de REST e as suas aplicações.
 � Identificar REST em aplicações como endpoint para aplicativos backend.
 � Praticar o uso de RESTful em uma aplicação de exemplo.
Introdução
Neste capítulo, você conhecerá os webservices REpresentational State 
Transfer (RESTful), serviços construídos com o estilo de arquitetura RESTful. 
A construção de webservices com a abordagem RESTful tem surgido como 
uma alternativa popular ao uso de tecnologias baseadas em SOAP (simple 
object access protocol) para implantação de serviços na internet, por ser 
mais leve e conseguir transmitir dados diretamente via HTTP (hypertext 
transfer protocol).
REST: o que é e onde se pode utilizá-la
Transferência representacional de estado (REST, do inglês representational 
state transfer) refere-se a um conceito de arquitetura para troca de dados 
entre sistemas distribuídos, como a world wide web (WWW). O conceito 
de recursos identificados por ID de recursos universais (URI) é central para 
a arquitetura RESTful. Esses recursos podem ser manipulados usando uma 
interface-padrão, como hypertext transfer protocol (HTTP), e as informações 
trocadas entre os sistemas empregando as representações desses recursos.
A REST tem como principal objetivo definir características fundamentais 
para a construção de aplicações na Web em conformidade com boas práticas. 
A Web como conhecemos atualmente funciona seguindo práticas REST, 
conforme podemos acompanhar pelo raciocínio a seguir.
1. Você digita um endereço no seu navegador.
2. Então, seu navegador estabelecerá uma conexão TCP/IP com o servi-
dor requisitado e enviará uma requisição GET HTTP com o endereço 
solicitado.
3. O servidor de destino interpretará a requisição e, de acordo com o que 
contiver, retornará uma resposta HTTP para seu navegador.
4. A resposta poderá ser de sucesso, contendo alguma representação em 
formato HTML, ou, então, uma mensagem de erro, como é comum 
encontrarmos com o famoso 404 Not Found, que, nesse caso, indica 
que o endereço ou recurso solicitado pelo seu navegador não pode ser 
encontrado.
5. Em caso de sucesso, seu navegador interpreta o HTML retornado e 
você navegará pela página renderizada.
A Figura 1 ilustra como funciona essa requisição a partir do navegador 
na Web.
Figura 1. Exemplo de requisição GET de um navegador.
Fonte: Victorio (2016, documento on-line).
Webservices RESTful2
Atualmente, a REST é o padrão mais utilizado como alternativa ao já 
considerado ultrapassado SOAP (simple object access protocol), cuja prin-
cipal reclamação associada refere-se à sua burocracia, algo que, na REST, 
é consideravelmente reduzido. Como já vimos, a REST baseia-se no design 
do protocolo HTTP, que já apresenta diversos mecanismos embutidos para 
representar recursos com código de status, tipos de conteúdo, cabeçalhos, 
etc. Nessa arquitetura, o fundamental são as URL (uniform resource locator) 
do sistema e os recursos (recurso é um recurso, entidade), fazendo uso dos 
métodos HTTP para promover a comunicação:
 � GET: solicita a representação de determinado recurso. Define-se como 
um método seguro e não deve ser usado para disparar uma ação (p. ex., 
remover um usuário).
 � POST: as informações enviadas no corpo (body) da requisição são 
utilizadas para criar um novo recurso. Também é responsável por fazer 
processamentos não diretamente relacionados a um recurso.
 � DELETE: remove um recurso. Deve retornar o status 204 caso não 
exista nenhum recurso para a URI especificada.
 � PUT: atualiza um recurso na URI especificada. Caso o recurso não 
exista, ele pode criar um. A principal diferença entre POST e PUT 
é que o primeiro pode lidar não somente com recursos, mas também 
pode processar informações.
Contudo, não existe um padrão obrigatório, podendo-se implementar 
somente o que é necessário em seu contexto.
REST API como back-end e front-end
A API (application programming interface) de um serviço Web (Web service) 
pode ser entendida como uma estrada que liga duas cidades distantes, até 
então impossível de ser conectadas sem esse caminho. No caso de aplicações, 
uma API pode ser utilizada por diferentes aplicações de negócio, sem que 
necessariamente cada aplicação conheça os detalhes da sua implementação.
Nesse sentido, as API são interfaces de integração entre aplicações que 
possibilitam a troca de informações entre elas, inclusive recursos que permitem 
que uma mesma aplicação apresente comportamentos específicos para uma 
versão móvel, outra desktop e outra Web.
3Webservices RESTful
Uma API pode ser acessada por meio de um endereço. Supomos que estamos 
acessando a API disponível por um Web service de uma escola para encontrar 
alguns registros disponíveis para os alunos. Perceba que isso é uma vantagem das 
API também, já que, nesse exemplo, os únicos dados retornados para a nossa apli-
cação são o nome e a idade do aluno. Mas o registro de alunos tem mais registros?
Sim, porém, como a nossa aplicação está consumindo essa API e não precisa 
se preocupar com a implementação da busca em si, apenas solicita a API e o 
Web service da escola implementa a busca, a partir da qual, por questões de 
negócio, são disponibilizadas apenas as informações de nome e idade.
Endereço da API (escola.com.br/api/v1/alunos)
Arquivo JSON de retorno para a nossa aplicação:
{
 "alunos":
 [
 {
 "nome": "Aluno1",
 "idade": 12
 },
 {
 "nome": "Aluno2",
 "idade": 13
 },
 {
 "nome": "Aluno3",
 "idade": 14
 },
 {
 "nome": "Aluno4",
 "idade": 15
 }
 ]
}
Webservices RESTful4
Com esse exemplo, podemos ter um caso de uma API em que várias aplicações 
clientes poderiam solicitar os dados dos alunos da escola e usariam essa informação. 
A REST nos permite criar uma API utilizando o protocolo HTTP para requisições.
Uma questão muito interessante quando se fala de Web services SOAP ou REST, às 
vezes não comentada, é o fato de que ambas tecnologias podem ser misturadas e 
combinadas. REST tem a característica de ser fácil de entender e extremamente acessível, 
embora possamos sentir falta de alguns padrões, sendo a tecnologia considerada 
uma abordagem arquitetural. Em contrapartida, o SOAP é o padrão da indústria, com 
protocolos bem definidos e um conjunto de regras estabelecidas. 
Algumas caraterísticas da REST
A REST possibilita uma série de benefícios, mas é importante lembrar que 
não se trata de um padrão, não sendo necessariamente obrigado a segui-la 
para criar Web services ou aplicações Web. Podemos classificá-la como uma 
espécie de “guia” com recomendações.
Cliente — Servidor
Característica básica para uma aplicação REST, o objetivo dessa segmentação 
consiste em separar a arquitetura e as responsabilidades em ambientes distintos. 
Dessa forma, a aplicação cliente, ou o consumidor do serviço, abstrai tarefas 
como comunicação com o banco de dados, gerenciamento de cache, logs, etc.
E o contrário também é verdadeiro: o servidor ou o provedor do serviço 
não precisa se preocupar com tarefas como interface, user experience, etc., 
possibilitando, assim, a evolução independente das duas arquiteturas.
Nesse modelo, o servidor espera pelas requisições do cliente, executa-as 
e devolve uma resposta (Figura 2).
5Webservices RESTful
Figura 2. Exemplo de arquitetura client server.
Fonte: Maziero (2008, documento on-line).
Stateless
Na arquitetura REST, uma aplicação cliente pode enviar requisições para a 
aplicação servidor, embora cada uma delas devam ser independentes, ou seja, 
toda requisição precisa conter algumas informações necessárias para que o 
servidor consiga interpretar e processar adequadamente.
Nesse modelo, o servidor também não deverá guardar nenhuma informação 
do estado do cliente, comosessões. 
Cacheable
Como muitas aplicações cliente farão consultas requisitando os mesmos 
serviços, é importante que essas informações possas ser cacheadas no ser-
vidor, evitando processamentos desnecessários e provendo uma melhoria no 
desempenho.
Na prática, quando uma aplicação cliente solicita pela primeira vez um 
serviço ao servidor, ele processa a requisição e armazena temporariamente na 
cache. Quando as demais aplicações solicitarem o mesmo serviço, o servidor 
devolve o que está em cache sem ter que reprocessar novamente.
Webservices RESTful6
Uniform Interface
Como um contrato entre aplicações cliente servidor para comunicação, trata-
-se de pequenas regras que permitem deixar um componente o mais genérico 
possível, facilitando a manutenção e a evolução.
Nessas regras, existe uma espécie de guideline para possibilitar a unifor-
midade dessa comunicação:
1. Identificação do recurso: cada recurso teve ter uma URI específica e 
coesa para permitir o seu acesso.
2. Representação do recurso: forma como as informações do recurso 
retornarão para a aplicação cliente, como em JSON, XML, HTML, 
TXT, etc.
3. Resposta autoexplicativa: é necessária a passagem de metainformações 
(metadata) na requisição, algumas das quais, na resposta, são, por 
exemplo, código HTTP da resposta, Host, Content-Type, etc.
4. Hypermedia: parte muitas vezes esquecida quando estamos falando 
de REST. Consiste em retornar todas as informações necessárias na 
resposta que permitam que a aplicação cliente navegue e tenha acesso 
a todos os recursos da aplicação.
Layered System
A aplicação deve ser composta por camadas, que possibilitarão a sua alteração, 
tanto para adicionar mais camadas quanto para permitir a sua remoção. Assim, 
um dos princípios dessa característica refere-se ao fato de que a aplicação 
cliente nunca deverá chamar diretamente o servidor sem antes passar por um 
intermediador, que pode ser um Load Balancer ou qualquer outra máquina 
que faça a interface com os servidores.
Isso possibilita que a aplicação cliente se preocupe apenas em se comunicar 
com o intermediador e este se responsabilize por distribuir as requisições 
para os servidores, que podem ser um ou muitos. Com esse conceito, a sua 
arquitetura ficará muito mais flexível.
7Webservices RESTful
Trabalhar com camadas possibilita melhorar a escalabilidade do processo, o que significa 
que é possível uma arquitetura composta por camadas hierárquicas condicionar o 
comportamento de componentes de modo que cada componente não pode “ver” 
além da camada imediata com as quais estão interagindo. A grande vantagem da 
imposição dessa restrição reside no fato de que a complexidade é restrita e podemos 
pensar que estas camadas encapsulam serviços (p. ex., serviços legados), etc. Como 
em todos os aspectos, isso deve ser levado em consideração na implementação para 
evitar sobrecargas entre as camadas — a implementação de cache por domínio é uma 
estratégia para quem quiser aproveitar dessa característica da REST.
Code-on-demand
Condição que possibilita a execução de código sob demanda pela aplicação 
cliente, ou seja, estender parte da lógica do servidor Web services para a 
aplicação cliente. Assim, diferentes aplicações clientes podem apresentar com-
portamentos específicos mesmo consumindo exatamente os mesmos serviços.
Como isso não faz parte da arquitetura em si, é considerado como opcional, 
podendo-se utilizá-lo para executar alguma parte do serviço pelo lado da 
aplicação cliente mais eficaz ou rápida.
Para uma API ser considerada RESTful, ela deve seguir estritamente as 
regras definidas na arquitetura REST (com exceção da code-on-demand, por 
ser opcional), além de dispor de certo nível de coesão e maturidade, definidos 
na escala Richardson maturity model (RICHARDSON..., 2019, documento 
on-line). 
Exemplo de uma aplicação Android 
consumindo Web services
A seguir, você verá um exemplo de código para consumo dos Web services 
do correio para busca de dados de um endereço a partir de um CEP (código 
de endereçamento postal). 
Webservices RESTful8
public class ViaCEP {
 private String CEP;
 private String Logradouro;
 private String Complemento;
 private String Bairro;
 private String Localidade;
 private String Uf;
 private String Ibge;
 private String Gia;
 /**
 * Constrói uma nova classe
 */
 public ViaCEP() {
 this.CEP = null;
 this.Logradouro = null;
 this.Complemento = null;
 this.Bairro = null;
 this.Localidade = null;
 this.Uf = null;
 this.Ibge = null;
 this.Gia = null;
 }
 /**
 * Constrói uma nova classe e busca um CEP no ViaCEP
 *
 * @param cep
 * @throws viacep.ViaCEPException caso ocorra algum erro
 */
 public ViaCEP(String cep) throws ViaCEPException {
 this.buscar(cep);
 }
9Webservices RESTful
 /**
 * Busca um CEP no ViaCEP
 *
 * @param cep
 * @throws viacep.ViaCEPException caso ocorra algum erro
 */
 public final void buscar(String cep) throws ViaCEPE-
xception {
 this.CEP = cep;
 // define a url
 String url = “http://viacep.com.br/ws/” + cep + “/
json/”;
 // define os dados
 JSONObject obj = new JSONObject(this.get(url));
 if (!obj.has(“erro”)) {
 this.CEP = obj.getString(“cep”);
 this.Logradouro = obj.getString(“logradouro”);
 this.Complemento = obj.getString(“complemento”);
 this.Bairro = obj.getString(“bairro”);
 this.Localidade = obj.getString(“localidade”);
 this.Uf = obj.getString(“uf”);
 this.Ibge = obj.getString(“ibge”);
 this.Gia = obj.getString(“gia”);
 } else {
 throw new ViaCEPException(“Não foi possível 
encontrar o CEP”, cep);
 }
 }
 public String getGia() {
 return this.Gia;
 }
Webservices RESTful10
 public final String get(String urlToRead) throws Via-
CEPException {
 StringBuilder result = new StringBuilder();
 try {
 URL url = new URL(urlToRead);
 HttpURLConnection conn = (HttpURLConnection) 
url.openConnection();
 conn.setRequestMethod(“GET”);
 BufferedReader rd = new BufferedReader(new 
InputStreamReader(conn.getInputStream()));
 String line;
 while ((line = rd.readLine()) != null) {
 result.append(line);
 }
 
 } catch (MalformedURLException | ProtocolExcep-
tion ex) {
 throw new ViaCEPException(ex.getMessage());
 } catch (IOException ex) {
 throw new ViaCEPException(ex.getMessage());
 }
 
 return result.toString();
 }
} 
A API ViaCep, que possibilita aplicações consultarem o código de endereçamento 
postal CEP de qualquer localidade no Brasil, é observada no link a seguir.
https://qrgo.page.link/QhWzN
11Webservices RESTful
MAZIERO, C. A. Introdução aos Serviços de Rede. Laboratório de Redes, Sistemas Distribuí-
dos e Segurança, Departamento de Informática, Universidade Federal do Paraná, Curitiba, 21 
nov. 2008. Disponível em: http://wiki.inf.ufpr.br/maziero/doku.php?id=espec:introducao. 
Acesso em: 10 jul. 2019.
RICHARDSON Maturity Model. REST API Tutorial, [S. l.], 2019. Disponível em: https://
restfulapi.net/Richardson-maturity-model/. Acesso em: 10 jul. 2019.
VICTORIO, J. C. A. Requisições GET e POST – Principais diferenças. TI – Tecnologia e 
Inovação – o seu portal de tecnologia, Rio de Janeiro, 24 jul. 2016. Disponível em: http://
tecnologiaeinovacao.com.br/blog/2016/07/24/requisicoes-get-e-post-principais-
-diferencas/. Acesso em: 10 jul. 2019.
Leituras recomendadas
ANDROID Developers. [S. l.: S. n.], 2019. Disponível em: https://developer.android.com. 
Acesso em: 10 jul. 2019.
DEITEL, P.; DEITEL, H.; DEITEL, A. Android: como programar. 2. ed. Porto Alegre: Book-man, 2015. 690 p.
DEITEL, P.; DEITEL, H.; WALD, A. Android 6 para programadores: uma abordagem baseada 
em aplicativos. 3. ed. Porto Alegre: Bookman, 2016. 618 p.
Webservices RESTful12