REST

FACULDADE DE TECNOLOGIA ZONA LESTE
GUILHERME DE OLIVEIRA SANTOS

VINICIUS ARAUJO RIBEIRO
Desenvolvimento de um framework para consumo de Webservice REST

em aplicaes Android
So Paulo
2013
FACULDADE DE TECNOLOGIA ZONA LESTE
GUILHERME DE OLIVEIRA SANTOS

VINICIUS ARAUJO RIBEIRO
Desenvolvimento de um framework para consumo de Webservice REST

em aplicaes Android
Trabalho de Concluso de Curso apresentado

Faculdade de Tecnologia da Zona Leste,
sob a orientao do (a) Professor (a) MSc
Wilson Vendramel, como requisito parcial
para a obteno do diploma de Graduao no
Curso de Anlise e Desenvolvimento de
Sistemas.
So Paulo
2013
RIBEIRO, Vinicius Araujo; SANTOS, Guilherme de Oliveria

Desenvolvimento de um framework para consumo de Webservice REST em
aplicaes Android / Vinicius Araujo Ribeiro, Guilherme de Oliveira Santos Faculdade de
Tecnologia da Zona Leste, So Paulo, 2013
80 p.
Orientador: Msc Wilson Vendramel

Trabalho de Concluso de Curso Faculdade de Tecnologia da Zona Leste
1. Android 2. Framework 3. Integrao de sistemas 4. Webservices 5. REST
RIBEIRO, Vinicius. A, SANTOS, Guilherme O.,Desenvolvimento de um Framework

para Consumo de Webservice REST em aplicaes Android. P.80, Trabalho de
Concluso de Curso, Faculdade de Tecnologia da Zona Leste, So Paulo, 2013.
RESUMO
Diversas plataformas disponibilizam API de Webservices REST para estender suas

funcionalidades e permitir uma maior interao com sistemas externos. Para o
consumo de Webservice REST no sistema operacional Android necessrio a
utilizao de bibliotecas nativas para efetuar requisies HTTP, uma abordagem que
precisa de desenvolvimento de cdigo que no pertence ao negcio. O objetivo
deste trabalho desenvolver um framework para consumo de Webservice REST
que encapsule funes genricas para ser reutilizado no desenvolvimento de
aplicaes Android, na busca de responder a seguinte questo: Como diminuir a
necessidade de cdigo no inerente ao negcio no desenvolvimento de uma
aplicao que precisa consumir Webservice REST? A hiptese levantada para sanar
essa questo a utilizao de um framework que encapsule funes comuns no
desenvolvimento de uma aplicao Android no que tange o consumo de Webservice
REST. Na execuo deste trabalho foi feito pesquisa bibliogrfica para dar
fundamentao terica sobre os assuntos tratados, tambm foi desenvolvido um
framework para simplificar o consumo de Webservices REST, encapsulando funes
comuns e oferendo uma API para o desenvolvedor utilizar no desenvolvimento de
aplicativos para o sistema operacional Android, e uma aplicao que utiliza o
framework demonstrando sua funcionalidade.
Palavras-chave: Android; Framework; Integrao de Sistemas; Webservices; REST.
RIBEIRO, Vinicius. A, SANTOS, Guilherme O., Development of a framework to

Consumption of Rest Webservices in Android Applications. P.80 Trabalho de
Concluso de Curso, Faculdade de Tecnologiada Zona Leste, So Paulo, 2013.
ABSTRACT
Several platforms provide Rest API Webservices to extend its functionality and allow
greater interaction with external products. For consuming Rest Webservice in
Android operating system is necessary to use native libraries to make HTTP
requests, an approach that needs development code that does not belong to the
business. This paper aims to develop a framework for consuming Webservie REST
that wraps generic functions to be reused in the development of Android applications,
seeking to answer the question: How to reduce the need for code not inherent in the
business in the development of an application that need to consume REST
webservice? The hypothesis to remedy this issue is to use a framework that
encapsulate common functions in the development of an Android application
regarding the consumption of REST webservice. To fulfill his work were made a
bibliographic research to give a theoretical validity about subjects addressed, was
also developed a framework to simplify the consumption of REST Webservices ,
encapsulating common functions and Offering an API for developer use in
developing applications for the Android OS and an application that uses the
framework demonstrating its functionality .
Keywords: System integration; Web Services; REST; Android; Framework.
Lista de Quadros
Quadro 1: Benefcios do reuso de software ......................................................................... 14

Quadro 2: Exemplo de URI .................................................................................................. 21
Quadro 3: Exemplo HATEOAS, ordem de compra com link para o cliente. ......................... 22
Quadro 4: Semntica CRUD/Verbos HTTP ......................................................................... 23
Quadro 5: Semntica verbo HTTP/URI ................................................................................ 24
Quadro 6: Comparao entre SOAP e REST ...................................................................... 26
Quadro 7: Mdulos do padro de projeto Service API ......................................................... 31
Quadro 8: Exemplo bsico de requisio HTTP com biblioteca nativa HttpUrlconnection .... 32
Quadro 9: Requisitos funcionais .......................................................................................... 33
Quadro 10: Mdulos do framework ...................................................................................... 35
Lista de Figuras
Figura 1: Interseco de funes comuns entre sistemas distintos. ..................................... 17
Figura 2: Exposio de servios atravs de Webservices que encapsulam uma infraestrutura
interna. ................................................................................................................................ 18
Figura 3: Interoperabilidade intrnseca na comunicao entre Webservices ........................ 19
Figura 4: Webservices expe uma interface de acesso via web para servios locais .......... 20
Figura 5: Estrutura Pattern Service API ............................................................................... 30
Figura 6: Diagrama de caso de uso ..................................................................................... 34
Figura 7: Arquitetura do Framework..................................................................................... 35
Figura 8: Diagrama de classes ............................................................................................ 37
Figura 9: Classe Resource................................................................................................... 38
Figura 10: Exemplo de Utilizao da Classe Resource ........................................................ 38
Figura 11: Classe RestExecutor .......................................................................................... 39
Figura 12: Exemplo de Utilizao da Classe RestExecutor .................................................. 39
Figura 13: Classe HttpHeader .............................................................................................. 40
Figura 14: Exemplo de Utilizao da Classe HttpHeader ..................................................... 40
Figura 15: Interface CallBack ............................................................................................... 41
Figura 16: Exemplo de Utilizao da interface CallBack ...................................................... 41
Figura 17: Interface PostCallback ........................................................................................ 41
Figura 18: Classe Response ................................................................................................ 42
Figura 19: Entidade Resource da base de dados ................................................................ 43
Figura 20: Exemplo de vinculao de objeto a um objeto Resource .................................... 44
Figura 21: Exemplo de requisio GET................................................................................ 44
Figura 22: Diagrama de sequncia GET .............................................................................. 45
Figura 23: Fragmento 1 do diagrama de sequncia do fluxo da operao GET ................... 47
Figura 27: Exemplo de uma requisio DELETE ................................................................. 51
Figura 28: Diagrama de sequncia DELETE ....................................................................... 52
Figura 29: Fragmento 1 do diagrama de sequncia do fluxo da operao DELETE ............ 54
Figura 33: Exemplo de uma requisio PUT ........................................................................ 58
Figura 34: Diagrama de sequncia PUT .............................................................................. 59
Figura 35: Fragmento 1 do diagrama de sequncia do fluxo da operao PUT ................... 61
Figura 39: Exemplo de uma requisio POST ..................................................................... 65
Figura 40: Diagrama de sequncia POST............................................................................ 66
Figura 41: Fragmento 1 do diagrama de sequncia do fluxo da operao POST ................ 68
Figura 45: Interface grfica da aplicao com lista de cursos existentes no Coursera ......... 73
Figura 46: Interface grfica da aplicao com detalhes de um curso no Coursera ............... 74
Figura 47: Uso do framework na aplicao do Coursera ...................................................... 75
Lista de Siglas
API - Application Programming Interface

B2B - Business-to-Business
BPEL - Business Process Execution Language
CRUD - Create, Retrieve, Update, Delete
ESB - Enterprise Service Bus
HATEOAS - Hypermedia as the Engine of Application State
HTTP - Hypertext Transfer Protocol
HTTPS - HyperText Transfer Protocol Secure
JSON - JavaScript Object Notation
MIME - Multipurpose Internet Mail Extensions
Ph.D. - Philosophiae Doctor
REST - Representation State Transfer
RSS - Really Simple Syndication
SOAP - Simple Object Access Protocol
SQL - Structured Query Language
UDDI - Universal Description Discovery and Integration
URI - Uniform Resource Identifier
URL - Uniform Resource Location
WADL - Web Application Description Language
WSDL - Web Service Description Language
XML - Extensible Markup Language
SUMRIO
1
INTRODUO.............................................................................................................. 11
FUNDAMENTAO TERICA .................................................................................... 14
2.1
WEBSERVICE....................................................................................................... 17
2.2
REST (REpresentation State Transfer) .................................................................. 20
2.3
HATEOAS - Hypermedia As the Engine of Application State ................................. 22
2.4
Uniform Interface ................................................................................................... 23
2.5
POST x PUT .......................................................................................................... 24
2.6
Stateless................................................................................................................ 25
2.7
SOAP x REST ....................................................................................................... 25
DESENVOLVENDO O FRAMEWORK ......................................................................... 28

3.1
O padro de projeto Service API ........................................................................... 28
3.2
Estrutura do Pattern Service API ........................................................................... 29
3.3
Consumindo Webservice REST no Android........................................................... 32
3.4
Funcionalidades do Framework ............................................................................. 33
3.5
Arquitetura do projeto ............................................................................................ 34
3.6
Classes Principais ................................................................................................. 37
3.7
Banco de Dados .................................................................................................... 42
3.7.1
3.8
Estrutura do Banco de Dados ......................................................................... 43
Exemplos bsicos: ................................................................................................. 44
3.8.1
GET: ............................................................................................................... 44
3.8.2
DELETE: ........................................................................................................ 51
3.8.3
PUT: ............................................................................................................... 58
3.8.4
POST:............................................................................................................. 65
DESENVOLVENDO UMA APLICAO........................................................................ 72

4.1
Pr-requisitos ........................................................................................................ 72
4.2
Funes................................................................................................................. 73
CONSIDERAES FINAIS .......................................................................................... 76
GLOSSRIO ................................................................................................................ 77
REFERNCIAS ............................................................................................................ 79
1 INTRODUO
A comunicao entre diferentes dispositivos e sistemas abre um grande parque para

inovao e novos produtos.
Novas tecnologias surgem para suprir essas novas necessidades. Uma dessas
tecnologias Webservice REST (REpresentation State Transfer), um meio de obter
interoperabilidade entre diferentes sistemas atravs da exposio de recursos na
Web de maneira genrica de forma que no importa quem o fornecedor ou o
consumidor, eles podero se comunicar.
Outra tecnologia que tem levado a conectividade e a mobilidade a outros patamares

so os sistemas operacionais mveis, dentre eles o Android, sistema operacional da
Google Inc. presente em celulares, smartphones, culos e at casas e carros.
Este trabalho prope um framework para o consumo de Webservice REST em

aplicaes Android.
O consumo de Webservice REST na plataforma Android desenvolvido utilizando

as bibliotecas nativas para efetuar requisies HTTP, porm existe a necessidade do
desenvolvimento de cdigo de infraestrutura e suporte para se obter uma aplicao
com qualidade e performance, e dependendo da situao, para que possa atender
aos requisitos do negcio.
Esses cdigos de infraestrutura e suporte referem-se lgica para controle

multithread, serializao de requisies assncronas, persistncia de dados, controle
transacional, entre outras, de modo que no so relacionados ao negcio, dessa
forma estes cdigos podem ser englobados em uma biblioteca de cdigo genrica
para ser reutilizado por qualquer projeto que precise de um componente que oferea
essas funes.
12
O reuso um conceito amplamente usado em engenharia de software, o

desenvolvimento de software baseado em componentes traz grandes benefcios,
como cerca de 70% de reduo do tempo do ciclo de desenvolvimento e 84% de
reduo do custo do projeto (PRESSMAN, 2011).
Referente ao consumo de Webservice na plataforma Android; esperado que nos

prximos 5 anos as redes de celulares tenham um aumento em 40 vezes em seu
trfego e o uso de REST tem ligeira vantagem no meio mvel tendo em vista que
oferece grande performance atravs de um sistema de mensagem mais leve.
Webservice baseado em SOAP tem duas grandes desvantagens: A alta
necessidade de recursos para processar XMLs e a performance sobrecarregada e
instvel de comunicao em comparao com outras abordagens de sistemas
distribudos, tanto que a prpria Google j demonstrou no ter interesse em suportar
Webservice SOAP no Android (COBRZAN, 2010).
relevante tambm indicar que o sistema operacional Android responde por 53% do
mercado dos Estados Unidos de smartphones e, de acordo com o Google, cerca de
500.000 dispositivos Android so ativados por dia (FIAWOO, SOWAH, 2013).
Sobre o modelo de arquitetura apresentada na hiptese de soluo deste trabalho,

vlido destacar o trabalho de Dornin et al. (2012), onde apresentam os problemas do
custo do desperdcio de recursos do Android e apresentam como soluo o uso de
uma interface assncrona para a interao com a rede e o uso de persistncia local
de informaes.
O objetivo deste trabalho desenvolver um framework para consumo de Webservice

REST que encapsule funes genricas para ser reutilizado no desenvolvimento de
aplicaes Android, para responder a seguinte questo: Como diminuir a
necessidade de cdigo no inerente ao negcio no desenvolvimento de uma
aplicao que precisa consumir Webservice REST?
A hiptese levantada utilizar um framework que encapsule funes comuns no

desenvolvimento de uma aplicao Android no consumo de Webservice REST.
13
Para o desenvolvimento deste trabalho, foi realizada uma pesquisa bibliogrfica a

fim de fornecer a fundamentao terica sobre os assuntos abordados, que so
apresentados no segundo captulo e que contm tcnicas e benefcios da
engenharia de software, principalmente as estratgias de reuso, os conceitos sobre
a tecnologia de Webservices e a arquitetura REST.
O terceiro captulo apresenta o desenvolvimento de um framework para o consumo

de Webservices REST, desenvolvido em linguagem de programao Java, para o
sistema operacional Android. Neste captulo, apresentada a arquitetura do
framework, suas funcionalidades e exemplos de utilizao.
O quarto captulo mostra uma aplicao para o sistema operacional Android com a
finalidade de testar o framework desenvolvido, utilizando um Webservice externo e
demonstrando suas funcionalidades.
O quinto captulo contm as consideraes finais, resultados obtidos e proposies

futuras.
14
2 FUNDAMENTAO TERICA
Engenharia de software baseada em reuso uma abordagem de desenvolvimento

que tenta maximizar a reutilizao de software existente. As unidades de software
que podem ser reutilizadas podem ter tamanhos radicalmente diferentes como um
objeto, uma funo, componentes e at aplicaes inteiras (SOMMERVILLE, 2007).
O quadro 1 apresenta os benefcios do reuso de software.
Quadro 1: Benefcios do reuso de software
Benefcio
Explicao
Software reutilizado, que j tenha sido
testado e utilizado em ambiente de
Aumento de confiabilidade
produo, mais confivel do que um

novo software porque em sua concepo
e implementao e uso falhas j foram
encontradas e corrigidas.
O custo do software existente j
conhecido,
embora
os
custos
de
desenvolvimento sejam sempre uma

questo de julgamento. Esse um fator
importante para o gerenciamento de
Diminuio do risco do processo
projetos, pois reduz a margem de erro

em estimativa de custo do projeto. Isto
particularmente verdadeiro quando os
componentes de software relativamente
grandes,
tais
subsistemas
so
reutilizados
Continua
15
Continuao
Em vez fazendo o mesmo trabalho mais
Uso efetivo de especialistas
e mais, estes especialistas de aplicativos

podem desenvolver software reutilizveis
que encapsulam o seu conhecimento.
Algumas normas, como padres de
interface
de
usurio,
implementadas
como
podem
um
ser
conjunto
padro de componentes reutilizveis.

Por exemplo, se os menus em uma
interface do usurio so implementados
Cumprimento de normas
usando componentes reutilizveis, todas

as
aplicaes
iro
apresentar
os
mesmos formatos de menu para os

usurios. O uso de interfaces padro
para o usurio melhora confiabilidade,
pois os usurios so menos propensos a
fazer erros quando apresentados com
uma interface familiar.
Trazendo um sistema para o mercado o
mais cedo possvel muitas vezes mais
importante do que os custos globais de
Desenvolvimento acelerado
desenvolvimento.
Reutilizar
software
pode acelerar o sistema de produo

porque tanto o desenvolvimento e tempo
de validao devem ser reduzidos.
Fonte: (SOMMERVILLE, 2007, p. 276, adaptado)
Ao longo dos anos, muitas tcnicas de desenvolvimento baseado em reuso foram

criadas, cada sistema possui diferentes nveis de potencial de reuso (indo desde
simples
funes
at
aplicaes
inteiras),
duas
dessas
tcnicas
so:
Desenvolvimento baseado em componentes e frameworks (SOMMERVILLE, 2007).
16
Um componente elemento funcional de um programa que incorpora a lgica e

estruturas de dados internas necessrias para o processamento, junto a uma
interface que habilita o componente a ser chamado e que dados possam ser
passados a ele (PRESSMAN, 2011).
Um framework um conjunto de classes que colaboram para realizar uma

responsabilidade para um domnio de um subsistema da aplicao, isto , um
subsistema que contm a soluo para um problema especfico (FAYAD, SCHMIDT,
1997).
De uma maneira mais especfica, um framework pode ser definido como uma
arquitetura desenvolvida com o objetivo de atingir a mxima reutilizao,
representada como um conjunto de classes abstratas e concretas, com grande
potencial de especializao (MATTSSON, 1996, p. 52).
O fato de que muitos sistemas de software contm componentes idnticos ou com

funes semelhante (que so desenvolvidos diversas vezes) nos trouxe a
necessidade do reuso (SAMETINGER, 1997).
Como apresenta a figura 1, a interseco (mesma famlia de problemas) entre

sistemas distintos, cria a oportunidade da criao de um framework, que encapsula
essa lgica de maneira genrica e fornece um componente que pode ser includo a
qualquer software que precise dessas funes (SAUV, 2011).
17
Figura 1: Interseco de funes comuns entre sistemas distintos.
Fonte: (SAUV, 2011, s. p)
2.1
WEBSERVICE
Integrao entre sistemas tem se tornado uma atividade crtica para que as
empresas mantenham a competitividade em todos os setores. A cooperao de
diferentes reas e at diferentes organizaes para a criao de produtos
complexos que atendam as necessidades tornou-se o ponto chave para a vantagem
competitiva em diferentes reas (HOBDAY, PRENCIPE, DAVIES, 2003).
Em um cenrio em que h a interao, entre diferentes empresas que precisam

integrar sistemas heterogneos e cada companhia precisa gerenciar e operar seus
prprios sistemas de software possvel oferecer essa integrao atravs do
paradigma da orientao a servios, onde funcionalidades de um software so
expostos como servios atravs de interfaces que podem ser invocado por clientes
(ALONSO, et al. , 2004).
A figura 2 apresenta esse modelo onde funcionalidades de uma infraestrutura

interna so acessadas atravs de um Webservice.
18
Figura 2: Exposio de servios atravs de Webservices que encapsulam uma infraestrutura

interna.
Fonte: (ALONSO, et al., 2004, p.134, adaptado)
Mesmo que a orientao a servios seja independente a tecnologia, a plataforma

tecnolgica mais utilizada a de Webservices (ERL, 2009).
A popularidade dos Webservices precedeu a da computao

orientada a servios. Como resultado, o uso inicial ocorreu
principalmente em solues distribudas tradicionais, em que eles
eram mais comumente usados para facilitar a integrao de canais
ponto-a-ponto. medida que a maturidade e a adoo dos padres
Webservices aumentaram, tambm aumentou o escopo de sua
utilizao (ERL, 2009, p. 31).
Webservice uma aplicao acessvel por outra aplicao atravs da Web, a qual
promove interoperabilidade entre linguagens por meio de uma linguagem
intermediria que tanto consumidor quanto fornecedor do servio conhecem
(ALONSO, et al., 2004).
Com a lgica de servio podendo ser acessada via um framework de comunicao

neutro em relao ao fornecedor (de tecnologia), o servio se torna disponvel para
um numero maior de consumidores e transformaes de tipos de dados entre
diferentes plataformas so desnecessrias (ERL, 2009).
19
A figura 3 apresenta que com um padro de comunicao diferentes tipos de

fornecedores e consumidores podem se comunicar, pois h uma interoperabilidade
oferecida pelo padro.
Figura 3: Interoperabilidade intrnseca na comunicao entre Webservices
Fonte: (ERL, 2009, p. 32, adaptado)

Webservices so desenvolvidos com um uso especfico em mente: a
de serem pontos de entrada para o sistema local. Assim, o principal
uso de um Webservice o de expor (atravs da interface) a
funcionalidade interna, deixando o sistema visvel e acessvel atravs
da Web, de forma controlada. Webservices so, portanto, anlogas
s wrappers sofisticados que encapsulam uma ou mais aplicaes,
fornecendo uma interface nica e um acesso Web (ALONSO, et al.,
2004, p. 134).
A figura 4 mostra esta abordagem, onde o cliente acessa os servios internos de um

fornecedor atravs de Webservices disponveis na internet.
20
Figura 4: Webservices expe uma interface de acesso via web para servios locais
Fonte: (ALONSO, et al., 2004, p.135, adaptado)
2.2
REST (REpresentation State Transfer)
O termo REST foi criado por Roy Fielding em sua dissertao de Ph.D., que pelo
prprio autor definido como estilo arquitetural para sistemas de hipermdia
distribudos (FIELDING, 2000, p. 76), isso significa que um estilo de arquitetura de
software; uma maneira de desenho da soluo para que hipermdias (udio, vdeo,
imagem, texto) sejam armazenadas e interconectadas pela rede atravs de
hyperlinks, um exemplo deste modelo maior rede hipermdia do mundo, a World
Wide Web (KALIM, 2009).
O acrnimo REST significa REpresentational State Transfer (Transferncia de

estado da representao), e representa efetivamente o envio de uma representao
de alguma informao em certo momento, este pedao de informao identificada
por um hyperlink o conceito de recurso (RICHARDSON, RUBY, 2009).
Um recurso qualquer coisa que seja importante o suficiente para que seja criado
um hyperlink para referenci-lo, qualquer pedao de informao a qual tenha um
hyperlink
um
recurso,
essa
(RICHARDSON, RUBY, 2009).
propriedade
chamada
de
adressability
21
Um recurso depende de um hyperlink para estar na Web, precisa ter um endereo,

este endereo uma URI (Uniform Resource Identifier) (RICHARDSON, RUBY,
2009).
Uma URI deve ser descritiva, deve identificar o recurso de maneira intuitiva, por
exemplo, em uma aplicao de uma loja, para um recurso chamado produto, sua
URI deve identificar este produto (RICHARDSON, RUBY, 2009).
O quadro 2 apresenta um exemplo, onde possvel identificar que a URI referencia

a release 1.0.3 do software.
Quadro 2: Exemplo de URI

http://www.example.com/software/releases/1.0.3.tar.gz
Fonte: (RICHARDSON, RUBY, 2009, p. 83)
URIs devem ter uma estrutura, devem identificar nomes para que o recurso possa
ser interpretado. A sintaxe da URI deve ser utilizada como a navegao em um
sistemas de arquivos hierrquico. Esta restrio no descrita e no uma regra
absoluta no modelo REST, mas orientado fortemente que as URIs sejam
construdas desta maneira (RICHARDSON, RUBY, 2009).
Uma URI deve ser organizada hierarquicamente, com os componentes em ordem

decrescente de significncia da esquerda para direita (MASINTER, BERNERS-LEE,
FIELDING, 2005). Um recurso contm uma URI, um hyperlink a qual ser utilizado
por um cliente para solicitar um pedao de informao a um servidor.
Esta informao que ser transferida a representao do recurso naquele dado

momento.
Os tipo MIME (Multipurpose Internet Mail Extensions) presentes no protocolo HTTP

podem descrever em qual formato essa representao ser transferida, se uma
imagem, um texto, udio, vdeo. (RICHARDSON, RUBY ,2009).
22
2.3
HATEOAS - Hypermedia As the Engine of Application State
Um Webservice REST no um endpoint, mas uma rede de recursos

interconectados, com um modelo de hipermdia que no determina somente
relaes entre diferentes recursos, mas a possibilidade de conectar e navegar entre
os recursos (ALARCON, BELLIDO, WILDE, 2011).
Outros estados (de recursos) podem ser embutidos na representao de um recurso

atravs de um link, esses links podem ser descobertos dinamicamente e utilizados
para acessar outros recursos (PAUTASSO, 2009).
O quadro 3 d um exemplo deste comportamento onde a ordem de compra de um

servio de e-commerce contm referncias (links) para outros recursos.
Quadro 3: Exemplo HATEOAS, ordem de compra com link para o cliente.
<order id="111">
<customer>http://customers.myintranet.com/customer/32133</customer>
<order-entries>
<order-entry>
<quantity>5</quantity>
<product>http://products.myintranet.com/product/111</product>
Fonte: (BURKE, 2010. p. 11, adaptado)
Esse conceito de navegao entre recursos atravs de hyperlinks carregados pela

representao do recurso chamado de HATEOAS (FIELDING, 2000).
23
2.4
Uniform Interface
Uma vez que um recurso tenha sido identificado, o conjunto de operaes que
podem ser aplicadas a ele fixo, atravs dos quatro mtodos (ou verbos): PUT,
GET, POST e DELETE do protocolo HTTP. Estas operaes semelhantes ao CRUD
(Create, Retrieve, Update e Delete (do ingls, criar, ler, atualizar e apagar)) se
aplicam a todos os recursos com semntica semelhantes. Cada um destes mtodos
invocado sobre um recurso usando uma requisio HTTP (PAUTASSO, 2009).
As operaes CRUD fornecem aes para interagir com os recursos, o quadro 4

apresenta como o protocolo HTTP fornece as mesmas operaes com quatros
verbos (GET, POST, PUT, DELETE) (KALIM, 2009).
Quadro 4: Semntica CRUD/Verbos HTTP
Retrieve - Ler um recurso (GET)

Create - Criar um recurso (POST em uma URI j existente, PUT em uma nova URI)
Update - Atualizar um recurso (PUT em uma URI j existente)
Delete - Deletar um recurso (DELETE)
Fonte: (KALIM, 2009, p. 122, adaptado)
O quadro 5 mostra que utilizando os verbos HTTP e uma URI possvel criar
diversas interaes entre o cliente e o servidor:
24
Quadro 5: Semntica verbo HTTP/URI
Verbo HTTP
URI
Significado
Cria um novo empregado

POST
empregados
de
acordo
com
as
informaes passadas
GET
empregados
GET
empregados?id=27
L uma lista de todos os

empregados
L o empregado com id
27
Atualiza toda a lista de

PUT
Empregados
empregados de
com
as
acordo
informaes
passadas
DELETE
Empregados
DELETE
empregados?id=27
Deleta
lista
de
empregados
Deleta o empregado com

id 27
Fonte: (KALIM, 2009, p.125 adaptado)
2.5
POST x PUT
POST e PUT contm diferenas sutis, um cliente utiliza PUT quando ele ir decidir
qual URI o novo recurso ter, mas o cliente ir utilizar POST quando o servidor ir
decidir qual ser a URI do novo recurso (RICHARDSON, RUBY, 2009).
25
O verbo POST utilizado para criao de recursos subordinados (PAUTASSO,

2009).
Por exemplo, em um tpico em um frum, um recurso que representa o tpico

(/frum/meutopico), quando um cliente faz cria um comentrio no tpico ele executa
um POST nesta URI j existente (/frum/meutopico), o servidor quem deve decidir
qual URI essa postagem ter, como por exemplo /frum/meutopico/comentarios/1. O
cliente no tem o poder de indicar como ser formado a URI que representa o novo
comentrio (recurso), porm o cliente pode criar um tpico, nomeando-o, e assim
decidir qual URI esse tpico ter. Neste caso ele deve executar um PUT em uma
nova URI (/frum/novotopico) (RICHARDSON, RUBY, 2009).
2.6
Stateless
A caracterstica Stateless (sem estado) indica que cada interao entre cliente e o
servidor deve conter toda a informao necessria para processar a requisio, ou
seja, no deve depender de nenhuma outra informao salva no servidor em alguma
outra operao. Essa propriedade melhora na visibilidade, pois o sistema de controle
no precisa ter a viso alm da prpria requisio. Tambm melhora confiabilidade
(pois mais fcil de recuperar uma falha parcial, que ocorreu apenas em uma
requisio) e em escalabilidade, pois simplifica a aplicao tendo em vista que o
servidor no precisa armazenar estados e gerenciar recursos entre as requisies
(FIELDING, 2000).
2.7
SOAP x REST
Webservices podem ser classificados em duas categorias principais: RESTful e

baseado em SOAP. Esta classificao baseada no estilo arquitetural e na
tecnologia utilizada (FEDA, KLAUS, 2010).
26
Em um trabalho de comparao, o resultado obtido do experimento de

manutenibilidade entre as duas abordagens demonstrou que REST mais
manutenvel do lado do servidor e que Webservices SOAP so mais manutenveis
do lado do cliente (OLIVEIRA, 2012).
De modo geral os servios WS-* tm a vantagem de ser bastante

difundidos atualmente nas empresas e organizaes de grande
porte, ideais em circunstncias que envolvem diferentes protocolos
de comunicao; em ferramentas middleware utilizadas na
integrao de sistemas complexos e de diferentes arquiteturas
(BPEL, ESB). Servios RESTful, por outro lado, tm uma boa
resposta em utilizaes que envolvam manipulaes de dados onde
resgatam as caractersticas da Web. Recomenda-se em aplicaes
mobile, onde o custo na troca de mensagens bastante elevado; em
blogs e sites de relacionamento, os quais so baseados em recursos
e demandam de chamadas RSS ou Atom; em servios de busca na
internet, que trabalham com um alto trfego de informaes (DAL
MORO, DORNELES, TRINDADE, 2009, p. 14).
O quadro 6 apresenta um quadro comparativo entre os diferentes estilos de

Webservices, REST e SOAP.
Quadro 6: Comparao entre SOAP e REST
Critrio
SOAP
REST
Cliente/Servidor
Alto acoplamento
Baixo acoplamento
Uma URI representa o
Uma URI para cada
endpoint
recurso
Qualquer
HTTP
URI
Camada de Transporte
(Protocolo)
Continua
27
Continuao
Cache
No suporta
No uniforme, descrita em
Interface
um documento (WSDL)
Suporta
Interface Uniforme
Qualquer, mas binrios

Tipo de dados
necessria converso em
Qualquer tipo diretamente
anexo.
Informao da operao
(mtodo)
Passagem de informao
Documento descritor
No corpo da mensagem
Informaes passadas no
corpo da mensagem
um novos webservices
Padres especficos do
Padres utilizados
SOAP (WSDL, UDDI, WSSecurity)
Segurana
Informaes passadas no
corpo da mensagem e na
URI
WSDL
No expansvel sem criar
Escalabilidade
Mtodo HTTP
Especificao WSSecurity
WADL
Expansvel sem ser

necessrio criar novos
webservices
Padres da WEB (URL,

HTTP, XML, MIME Types)
Segurana HTTP
Fonte: (FEDA, KLAUS, 2010, p 174 adaptado)
28
3 DESENVOLVENDO O FRAMEWORK
Nesta seo ser apresentado o desenvolvimento do framework, sua arquitetura,

requisitos e exemplos de utilizao:
3.1
O padro de projeto Service API
O projeto baseado em um padro de projeto descrito pelo engenheiro de software

da Google Inc., Virgil Dobjanschi, chamado de Service API.
O padro de projeto foi criado para auxiliar os desenvolvedores a criar aplicaes

mais robustas com relao ao consumo de Webservice REST. A abordagem
tradicional continha dois grandes problemas, a qual o padro de projeto foi feito para
tratar.
O primeiro referente ao gerenciamento de threads em paralelo pelo sistema

operacional Android. Ao ter a necessidade de consumir um Webservice, natural
pensar em problemas sobre a comunicao tendo em vista que a comunicao com
o servidor, o tratamento da resposta, o estado da rede, tudo pode ser demorado; a
abordagem normal a de executar a requisio em uma thread separada da thread
principal, porm no Android as threads criadas de maneira convencional no fazem
parte do ciclo de vida dos processos do sistema operacional, e o Android, caso
necessrio, ir encerrar a thread sem o processamento terminar. Para sanar esse
problema necessrio a criao de um componente especfico, chamado Service
(ou uma de suas variaes como AsyncTask, IntentService), esse componente
conhecido e gerenciado pelo sistema operacional, utilizado exatamente para
execues em segundo plano de longa durao e o Android no ir encerrar este
processo de maneira abrupta (DOBJANSCHI, 2010).
29
O segundo problema com relao persistncia de dados. Manter os dados

obtidos pelo Webservice somente na memria voltil do dispositivo pode ser
altamente custoso, pois caso a aplicao seja encerrada, o dispositivo seja
desligado ou outro fator que faa com que os dados sejam perdidos, ser necessrio
executar novamente as requisies pela Web para recuperar os dados, causando
grande gasto de recursos como bateria, dados, memria e processamento de
maneira desnecessria (DOBJANSCHI, 2010).
3.2
Estrutura do Pattern Service API
O pattern Service API estruturado em componentes com funes distintas, a figura

5 mostra cada componente e a interao entre os componentes:
30
Figura 5: Estrutura Pattern Service API
Fonte: (DOBJANSCHI, 2010, s. p., adaptado)
O quadro 7 apresenta uma breve explanao sobre cada mdulo descrito no padro
Service API.
31
Quadro 7: Mdulos do padro de projeto Service API
Mdulo
Explicao
Responsvel por preparar a requisio
HTTP, tanto a URI quanto o corpo da
Rest Method
mensagem,
alm
da
execuo
da
requisio e processar a resposta.

O Processor utilizado para efetuar
controle
Processor
das
incluses
requisies
de
flags
efetuando
sobre
se
uma
requisio est sendo executada e se foi

finalizada.
Responsvel por receber requisies do
componente Service Helper e invocar a
Service
requisio
correspondente
Method,
deve
ao
tambm
Rest
executar
Callbacks para Service Helper.

Expe uma API assncrona para ser
utilizada
pela
Activity,
deve
fazer
validaes iniciais sobre a requisio (se

existe comunicao com a rede, por
exemplo), verifica se requisio esta
pendente,
Service Helper
cria
Intent(utilizado
para
componente
invocar
componente Service), adiciona id

requisio,
especficos
adiciona
da
parmetros
requisio
(como
informaes para autenticao), retorna

ID da requisio para o chamador e
deve executar Callback para Activity.
Continua
32
Continuao
A
Activity
componente
que
representa a tela que interage com o

usurio, Virgil Dobjanschi orienta sobre o
Activity
ciclo de vida da Activity, o qual deve ter

manipuladores das requisies sobre os
estados da Activity(onResume, onPause,
etc..).
Gerenciam o acesso a uma estrutura de
ContentProvider e CursosAdapter
dados.
Fonte: (DOBJANSCHI, 2010, s. p., adaptado)
3.3
Consumindo Webservice REST no Android
O consumo de Webservice no Android feito utilizando as bibliotecas nativas para

executar requisies HTTP, o quadro 8 apresenta um exemplo de uma requisio
bsica.
Quadro 8: Exemplo bsico de requisio HTTP com biblioteca nativa HttpUrlconnection
Fonte: Developer Android, s,d,, s,p.
Diversas outras funcionalidades devem ser desenvolvidas, funes relacionadas

segurana, tratamento de resposta, controle multithread, controle transacional.
33
3.4
Funcionalidades do Framework
O framework encapsula funes genricas e expe uma API para ser utilizada pela
aplicao, as funcionalidades encapsuladas so apresentadas no quadro 9 onde so
descritos os requisitos funcionais:
Quadro 9: Requisitos funcionais
Requisito
Descrio
O framework deve expor uma API para executar
API assncrona para o consumo

de Webservice REST sobre o
protocolo HTTP.
requisies HTTP para Webservice REST. Esta

API deve conter mtodos para a execuo dos
verbos HTTP para cada operao CRUD,
representados no protocolo HTTP pelos os
verbos GET, POST, PUT e DELETE.
Tendo em vista que as requisies HTTP sero
assncronas, necessrio garantir a integridade
dos dados, pois requisies como POST,
Serializao de chamadas
assncronas
DELETE e PUT afetam a representao do

recurso no servidor. A serializao deve manter
a
integridade
dos
dados
de
forma
que
operaes sobre o mesmo recurso devem ser

serializadas para que executem na mesma
ordem a qual foram requisitadas.
O
Persistncia e recuperao de
dados offline
framework
deve
requisies para
persistir
dados
das
recuperao offline, para
continuidade da execuo da aplicao em

casos de erros, perda do sinal, indisponibilidade
de acesso rede, etc.
Continua
34
Continuao
O framework deve controlar a
execuo de mltiplas threads e
do componente Service (utilizado
para execues em segundo
plano de longa durao).
O framework deve garantir o inicio da execuo

do componente Service em uma nova thread
quando necessrio e deve garantir a liberao
dos recursos quando no for mais necessrio.
Fonte: Os autores, 2013.
A figura 6 apresenta os requisitos em forma de um diagrama de caso de uso:

Figura 6: Diagrama de caso de uso
3.5
Arquitetura do projeto
O framework se baseia no modelo de Virgil Dobjanschi e contm uma arquitetura

interna semelhante, a figura 6 apresenta os componentes do framework:
35
Figura 7: Arquitetura do Framework
O quadro 10 apresenta cada mdulo e sua funo.

Quadro 10: Mdulos do framework
Mdulo
Funo
Expe
RestExecutor
API assncrona
para
ser
utilizado pela aplicao, alm de efetuar

validaes iniciais para a requisio.
Recebe chamada do RestExecutor, faz
validaes secundrias e decide se a
operao ser executada, tem a funo
de
iniciar
nova
thread
em
um
componente ServiceExecutor (o qual

corresponde ao Service, componente do
ServiceHelper
sistema
execues
operacional
de
longa
Android
durao
para
em
segundo plano).
Tambm tem a funo de persistir o
recurso incluindo uma flag indicando que
o objeto est sendo processado, alm de
informar o chamador que a operao foi
encaminhada.
Continua
36
Continuao
Junto com
ServiceHelper, orquestra a
requisio ao Webservice, cria objetos

para
requisio
com
chamada
ao
HTTPHelper, solicita a execuo da

ServiceExecutor
requisio HTTP ao HTTPExecutor, cria

objetos para resposta com chamadas ao
HTTPHelper,
persiste
dados
com
chamadas ao PersistExecutor, executa

Callbacks para aplicao quando a
requisio est terminada.
Persist Executor
Responsvel por efetuar persistncia de

dados em banco de dados local.
Responsvel por preparar e executar as
HTTPExecutor
requisies HTTP, alm de preparar as

respostas obtidas.
Prepara objetos para requisies HTTP,
utiliza o Parser para transformaes de
objetos Java para texto (XML,JSON,
etc.), que sero introduzidos no corpo
HTTPHelper
das mensagens HTTP.

Prepara objetos para resposta HTTP,
utiliza o Parser para transformaes de
texto (XML, JSON) para objetos Java,
que sero retornados para o solicitante.
Parser
Efetua transformao de objetos Java

para texto XML e JSON, e vice-versa.
37
3.6
Classes Principais
A figura 8 ilustra o diagrama de classes do framework:
Figura 8: Diagrama de classes
38
A classe Resource a principal classe do framework, nela vinculado um objeto da

aplicao com a maneira de acessar a representao deste objeto no servidor,
sendo isto uma URI, e possveis campos em um cabealho HTTP.
A figura 9 apresenta os detalhes da classe.
Figura 9: Classe Resource
Fonte: Os autores, 2013
A figura 10 apresenta um exemplo de utilizao, onde um objeto do tipo produto

vinculado ao recm-criado recurso. A partir deste momento temos um objeto da
aplicao (produto1) vinculado a um recurso (recursoProduto1), dessa forma
possvel efetuar requisies HTTP atravs da URI informada.
Figura 10: Exemplo de Utilizao da Classe Resource
A classe RestExecutor representa um singleton o qual expe a API assncrona para

requisies HTTP.
39
A figura 11 apresenta detalhes da classe que contm mtodos para as chamadas

aos quatro verbos HTTP utilizados no projeto e solicita sobre qual objeto efetuar a
operao.
Figura 11: Classe RestExecutor
A figura 12 demonstra a utilizao da API, executando o verbo GET do protocolo

HTTP atravs do mtodo GET do objeto (alm da implementao annima de um
Callback).
Figura 12: Exemplo de Utilizao da Classe RestExecutor
A Classe HttpHeader contm informaes que devem ser adicionadas ao cabealho

HTTP para efetuar a requisio, como por exemplo, informaes de localidade ou
para autenticao. A figura 13 apresenta a estrutura interna da classe.
40
Figura 13: Classe HttpHeader
A figura 14 contm um exemplo, onde anexado um recurso um novo objeto do

tipo HttpHeader, nele
foi includo uma nova informao a ser adicionada ao
cabealho da requisio HTTP.
Figura 14: Exemplo de Utilizao da Classe HttpHeader
A interface Callback utilizada para criar callbacks que sero invocados ao receber
a resposta do servidor sobre a requisio, criado na chamada do mtodo na API
assncrona pela aplicao, a figura 15 contm a definio da interface.
41
Figura 15: Interface CallBack
A figura 16 apresenta uma implementao annima da interface, a qual ser

invocada quando a requisio HTTP for terminada.
Figura 16: Exemplo de Utilizao da interface CallBack
A interface PostCallback semelhante interface Callback, porm utilizado em

uma chamada ao POST, esta interface entrega aplicao a nova URI criada para o
novo recurso, a figura 17 contm a definio da interface PostCallback.
Figura 17: Interface PostCallback
42
A classe Response contm a resposta do servidor sobre a requisio HTTP,

utilizada pela aplicao no callback para recuperar informaes como cdigo de
resposta da operao e o objeto retornado, a figura 18 contm a especificao da
classe Response.
Figura 18: Classe Response
3.7
Banco de Dados
O framework deve persistir dados para acesso offline, para tal ele contm um banco
de dados genrico que armazena os recursos utilizados pela aplicao cliente.
Para o funcionamento do framework, o banco de dados tambm armazena o vnculo

entre um objeto da aplicao e um objeto do tipo Resource (que contm as
informaes necessrias para acessar a representao do objeto em um servidor),
43
permitindo chamadas transparentes diretamente do objeto da aplicao.
3.7.1 Estrutura do Banco de Dados
O sistema operacional Android contm um banco de dados nativo chamado SQLite,

o qual ser utilizado no projeto. O banco de dados contm somente uma tabela, a
qual apresentada na figura 19.
Figura 19: Entidade Resource da base de dados
44
3.8
Exemplos bsicos:
Nesta seo so apresentados exemplos bsicos da utilizao com as quatro

operaes CRUD, utilizando os verbos HTTP: GET, POST, PUT, e DELETE,
seguidos de diagramas de sequncia que demonstram o fluxo executado no
framework:
3.8.1 GET:
A figura 20 apresenta o vnculo de um objeto da aplicao um objeto recurso, a

figura 21 demonstra a invocao do verbo GET do protocolo HTTP, atravs da
execuo do mtodo get do objeto restExecutor.
Figura 20: Exemplo de vinculao de objeto a um objeto Resource
Fonte: Os autores
Figura 21: Exemplo de requisio GET
A figura 22 contm um digrama de sequencia fragmentado que demonstra o fluxo da

operao GET, as figuras 23, 24, 25 e 26 complementam os fragmentos.
45
Figura 22: Diagrama de sequncia GET
46
A figura 23 (Fragmento 1 do diagrama de sequncia do fluxo da operao GET)

contm a busca pelo recurso vinculado ao objeto na base de dados (mtodo
findResourceByObjectKey()) e a persistncia de atualizaes sobre o objeto
proveniente da aplicao (mtodo persistResource()).
A figura 24 (Fragmento 2 do diagrama de sequncia do fluxo da operao GET) inicia

a preparao para executar o mtodo HTTP GET (mtodo invokeMethod) e tem a
solicitao para processar a requisio HTTP em uma nova thread (mtodo
startService()).

contm o inicio do processamento j na nova thread (mdoto onHandleIntent()) e a
requisio ao servidor pelo HttpExecutor (mtodo openUrlConnection()), alm do
processamento da resposta(mtodo generateResponse()).

contm a preparao (mtodo transformContentResponseInObject()) e execuo
(mtodo sendBroadcast()) dos callbacks vinculados quele recurso.
47
Figura 23: Fragmento 1 do diagrama de sequncia do fluxo da operao GET
Figura 15: Parte 1 do diagrama de sequncia do fluxo da operao GET
48
49
50
51
3.8.2 DELETE:
A figura 27 demonstra a chamada execuo do verbo DELETE do protocolo HTTP,

atravs da execuo do mtodo delete do objeto restExecutor.
Figura 27: Exemplo de uma requisio DELETE

operao DELETE, as figuras 29, 30, 31 e 32 complementam os fragmentos.
52
Figura 28: Diagrama de sequncia DELETE
53
A figura 29 (Fragmento 1 do diagrama de sequncia do fluxo da operao DELETE)


inicia a preparao para executar o mtodo HTTP DELETE (mtodo invokeMethod)
e tem a solicitao para processar a requisio HTTP em uma nova thread (mtodo
startService()).


54
Figura 29: Fragmento 1 do diagrama de sequncia do fluxo da operao DELETE
55
56
57
58
3.8.3 PUT:
A figura 33 demonstra a vinculao de um objeto cliente um objeto recurso, alm

da execuo da operao PUT atravs no mtodo homnimo
do objeto
restExecutor:
Figura 33: Exemplo de uma requisio PUT

operao PUT, as figuras 35, 36, 37 e 38 complementam os fragmentos.
59
Figura 34: Diagrama de sequncia PUT
60
A figura 35 (Fragmento 1 do diagrama de sequncia do fluxo da operao PUT)


inicia a preparao para executar o mtodo HTTP PUT (mtodo invokeMethod) e
tem a solicitao para processar a requisio HTTP em uma nova thread (mtodo
startService()).


61
Figura 35: Fragmento 1 do diagrama de sequncia do fluxo da operao PUT
62
63
64
65
3.8.4 POST:
A chamada ao POST um pouco diferente, tendo em vista que sua funo criar
um recurso vinculado a outro e que a definio da URI deve ser feita pelo servidor, o
POST executado sobre o "recurso pai" e repassado qual recurso deve ser
vinculado ele. A URI do novo recurso repassada no Callback.
A figura 39 demonstra a execuo de uma operao POST.
Figura 39: Exemplo de uma requisio POST

operao POST, as figuras 41, 42, 43 e 44 complementam os fragmentos.
66
Figura 40: Diagrama de sequncia POST
67
A figura 41 (Fragmento 1 do diagrama de sequncia do fluxo da operao POST)


inicia a preparao para executar o mtodo PUT e tem a solicitao para processar
a requisio HTTP em uma nova thread (mtodo startService()).

A figura 44 (Par Fragmento te 4 do diagrama de sequncia do fluxo da operao

POST) contm a preparao (mtodo transformContentResponseInObject()) e
execuo (mtodo sendBroadcast()) dos callbacks vinculados quele recurso.
68
Figura 41: Fragmento 1 do diagrama de sequncia do fluxo da operao POST
69
70
71
72
4 DESENVOLVENDO UMA APLICAO
Este captulo apresenta um aplicativo criado utilizando o framework. A aplicao

utiliza servios expostos do http://coursera.org/ para duas funes: Listar cursos
existentes e exibir detalhes de um curso selecionado.
Coursera uma empresa de educao que tem parceria com as melhores

universidades e organizaes em todo o mundo para oferecer cursos on-line para
que todos possam acessar de forma gratuita (COURSERA, 2013).
4.1
Pr-requisitos
Para desenvolver a aplicao so necessrios alguns pr-requisitos relacionados a

funcionalidade do framework:
1 Adicionar o arquivo jar do framework ao projeto da aplicao, para utilizar as

classes do framework.
2 Adicionar a biblioteca Gson ao projeto, esta biblioteca utilizada pelo framework

como motor de transformao entre objetos Java para JSON e vice-versa.
3 Registrar no arquivo de descrio da aplicao (AndroidManifest.xml) o

componente Service utilizado pelo framework (para processamentos assincronos em
segundo plano).
4 Registrar na aplicao o componente BroadCasterReceiver com a tag do

framework (para que a aplicao possa receber os callbacks do framework).
73
4.2
Funes
Esta aplicao apenas um prottipo e serve apenas como teste de validao do

framework, dessa forma a aplicao tem apenas duas funes:
1. Listar cursos existentes
A figura 45 apresenta a interface grfica que corresponde a lista de cursos, a URI

utilizada para receber a lista de cursos, disponibilizada pela plataforma do Coursera
(foi limitado o nmero de cursos exibidos de maneira hardcoded devido ao grande
nmero de resultados que retornado e por ser apenas uma aplicao de teste).
Figura 45: Interface grfica da aplicao com lista de cursos existentes no Coursera
74
2. Exibir detalhes de um curso selecionado
A figura 46 contm a interface grfica que apresenta os detalhes de um curso

selecionado na lista, a URI utilizada pra receber as informaes especficas de um
curso, disponibilizada pela plataforma do Coursera :
https://www.coursera.org/maestro/api/topic/information?topic-id=algs4partI
Onde algs4partI o id que identifica o curso e deve ser passada como valor do
parmetro topic-id.
Figura 46: Interface grfica da aplicao com detalhes de um curso no Coursera
75
Na figura 47 apresentado todo o cdigo utilizado na aplicao, com relao

requisio HTTP, para buscar um curso.
Figura 47: Uso do framework na aplicao do Coursera
76
5 CONSIDERAES FINAIS
O consumo de Webservices no sistema operacional Android uma tarefa complexa

e que demanda bastante cdigo no inerente ao negcio apenas para suportar a
funo.
Ao desenvolver a aplicao foi possvel consumir Webservices sem a necessidade

de utilizar as bibliotecas bsicas para requisio HTTP presente no sistema
operacional Android. As funes de consumo de Webservice referentes ao
processamento de metadados (JSON), persistncia local das informaes,
gerenciamento de thread (com relao ao consumo de servio) e dos componentes
do sistema operacional Android que permitem a execuo assncrona foram
totalmente encapsulados pelo framework e sendo totalmente transparente
aplicao e ao desenvolvedor (que se limita a atender aos pr-requisitos descritos
no desenvolvimento da aplicao).
Utilizando somente a API oferecida pelo framework foi possvel consumir servios,
promovendo um grande reuso de cdigo e consequentemente, um menor esforo no
desenvolvimento.
Para tornar o framework um produto robusto para utilizao em maior escala so

necessrios outros tipos de teste, resultando em possveis melhorias, dentre as
quais o tratamento de erros.
O framework necessita ser mais transparente aplicao, principalmente para

eliminar a necessidade de registrar o objeto da aplicao ao recurso por meio da
chamada um mtodo. Tambm necessrio o desenvolvimento de mdulos para
configurao, tornando o framework mais verstil, e funes de segurana,
implementando conexes HTTPS e criptografia.
77
6 GLOSSRIO
Activity - Componente do sistema operacional Android que geralmente representa

uma tela da aplicao.
Android - Android um sistema operacional baseado no ncleo do Linux6 para
dispositivos mveis, desenvolvido pela Open Handset Alliance, liderada pelo Google
e outras empresas.
Atom - Protocolo de contedo da Web baseado em XML
AsyncTask - Componente do sistema operacional Android utilizado para executar
operaes em segundo plano.
BinderCallback - Compenente do sistema operacional Android para efetuar
callbacks atravs de Intents
BPEL - Linguagem executvel para especificar aes de processos de negcios
dentro de web services.
BroadCasterReceiver - Componente do sistema operacional Android para efetuar
multiplas notificaes a diversos elementos da plataforma.
Callback - Cdigo que esperado que se execute ao final de determinado
processamento.
ContentObserver - Componente do sistema operacional Android que recebe
callbacks.
ContentProvider - Componente do sistema operacional Android que gerencia o
acesso a uma estrutuda de dados.
CursorAdapter - Componente do sistema operacional Android que adapta diversos
elementos como listas.
Endpoint - Ponto de acesso de determinada aplicao
78
Gson - Biblioteca de cdigos em Java desenvolvida pela Google Inc. para converso
de objetos Java em represetaes JSON e vice-versa.
Implementao annima - Implementao (e instanciao de um objeto)de uma
classe que no contm nome e utilizada somente localmente.
Intent - Componente do sistema operacional Android que indica a solicitao de
execuo de alguma ao.
IntentService - Componente do sistema operacional Android que solicita a
execuo de uma ao assncrona (atravs de um Intent)
JSON - um formato leve para intercmbio de dados computacionais.
Service - Componente do sistema operacional Android utilizado para executar
operaes em segundo plano, geralmente vinculado a um processo que deve
executar por tempo indeterminado.
Singleton - Padro garante a existncia de apenas uma instncia de uma classe,
mantendo um ponto global de acesso ao seu objeto.
SQLite - Banco de dados nativo no sistema operacional Android
UDDI - Servio de diretrio onde possvel publicar e descobrir Webservices
WADL - Documento XML que descreve aplicaes Webservices baseadas na
arquitetura REST
WS-* - Conjunto de especificaes para Webservices
WS-Security - Especificao para diretrizes de segurana para Webservices
WSDL - Documento XML que descreve aplicaes Webservices baseadas em
SOAP
79
7 REFERNCIAS
ALONSO, Gustavo; CASATI, Fabio; KUNO, Harumi; MACHIRAJU, Vijay. Web

Services Concepts, Architectures and Applications. Berlin: Springer, 2004.
ALARCON, Rosa; BELLIDO, Jesus; WILDE, Erik. Hypermedia-driven RESTful
service composition in Service-Oriented Computing. Berlin: Springer, 2011.
BURKE, Bill. RESTful Java with Jax-RS. Sebastopol: O'Reilly, 2010.
COBRZAN, Alin. Consuming Web Services on Mobile Platform, Faculty of
Economic Sciences. Cluj-Napoca: Informatica Economica Journal, 2010.
COURSERA,
About
24.Outubro.2013 s 12h14.
us,
https://www.coursera.org/about,
acessado:
DAL MORO, Tharcis; DORNELES, Carina Friedrich; TRINDADE, Marcelo. Web

services WS-* versus Web Services REST, Rio Grande do Sul: Universidade de
Passo Fundo, 2009.
DEVELOPER
ANDROID,
s.d;
Disponvel
em:
http://developer.android.com/reference/java/net/HttpURLConnection.html, acessado:
07. Maio. 2013 s 12h14.
DOBJANSCHI, Virgil. Developing Android REST Client Applications. s,d.
Disponivel em: https://dl.google.com/googleio/2010/android-developing-RESTfulandroid-apps.pdf. Acesso em: 07.Maio.2013 s 12h14.
DORNIN, Laird; MEDNIEKS Zigurd, MEIKE G. Blake, NAKAMURA, Masumi,
Programming Android: Java Programming for the New Generation of Mobile
Devices. Sebastopol: O'Reilly , 2012.
ERL, Thomas. SOA Princpios e Design, So Paulo: Pearson Education do Brasil,
2009.
FAYAD, Mohamed E., SCHMIDT, Douglas C. Object-oriented Application
frameworks. Communications of the ACM, Vol. 40, 1997.
FEDA AlShahwan, KLAUS Moessner. Providing SOAP Web Services and RESTful
Web Services from Mobile Hosts. Guildford: University of Surrey, 2010.
FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based
Software Architectues. Irvine, Estados Unidos. University of California, 2000. 161.
Dissertao, Doctor of Philosophy in Information and Computer Science.
FIAWOO Seth Y., SOWAH Robert A., Design and Development of a Web Service
for Android Applications for Extensive Data Processing, Accra: University of
80
Ghana, 2013.
HOBDAY, Michael, PRENCIPE, Andrea; DAVIES, Andrew; The Business Of
Systems Integration. Oxford: Oxford University Press, 2003.
JOHNSON, Ralph E. Frameworks=(components+patterns). Communications of
the ACM, v. 40, n. 10, p. 39-42, Ralph.
KALIM, Martin. Java Web Services: Up and Running. Sebastopol: OReally, 2009.
MASINTER, Larry; BERNERS-LEE, Tim; FIELDING, Roy T. Uniform resource
identifier (URI): Generic syntax. 2005. http://tools.ietf.org/html/rfc3986
MATTSSON, Michael. Object-oriented frameworks. Ronneby: University College of
Karlskrona/Ronneby, Licentiate thesis, 1996.
OLIVEIRA, Ricardo R. Avaliao de manutenibilidade entre as abordagens de
web services RESTful e SOAP-WSDL. Mestre em cincias da computao, USP
So Carlos, 2012.
PAUTASSO, Cesare. RESTful Web service composition with BPEL for REST,
Lugano: Elsevier, 2009
PRESSMAN, Roger S. Engenharia de software, Uma Abordagem Profissional
Stima Edo. So Paulo: McGraw HillHigher Education, 2011.
RICHARDSON, Leonard; RUBY, Sam. Restful Web Services. Sebastopol: OReally,
2009.
SAMETINGER, Johannes. Software engineering with reusable components. Linz:
Springer, 1997.
SAUV Jaques, P. Frameworks O que um Framework?, 2011. Universidade
de
Campina
Grande.
Disponvel
em:
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/oque.htmacessado:25/0
9/2013 s 23:45
SOMMERVILLE, Ian. Software Engineering Eighth Edition. USA, Pearson
Education Limited, 2007.

REST

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

REST

Transféré par

Droits d'auteur :

Formats disponibles

FACULDADE DE TECNOLOGIA ZONA LESTE

GUILHERME DE OLIVEIRA SANTOS

Desenvolvimento de um framework para consumo de Webservice REST

FACULDADE DE TECNOLOGIA ZONA LESTE

GUILHERME DE OLIVEIRA SANTOS

Desenvolvimento de um framework para consumo de Webservice REST

Trabalho de Concluso de Curso apresentado

RIBEIRO, Vinicius Araujo; SANTOS, Guilherme de Oliveria

Orientador: Msc Wilson Vendramel

1. Android 2. Framework 3. Integrao de sistemas 4. Webservices 5. REST

RIBEIRO, Vinicius. A, SANTOS, Guilherme O.,Desenvolvimento de um Framework

Diversas plataformas disponibilizam API de Webservices REST para estender suas

RIBEIRO, Vinicius. A, SANTOS, Guilherme O., Development of a framework to

Quadro 1: Benefcios do reuso de software ......................................................................... 14

API - Application Programming Interface

FUNDAMENTAO TERICA .................................................................................... 14

REST (REpresentation State Transfer) .................................................................. 20

HATEOAS - Hypermedia As the Engine of Application State ................................. 22

Uniform Interface ................................................................................................... 23

POST x PUT .......................................................................................................... 24

SOAP x REST ....................................................................................................... 25

DESENVOLVENDO O FRAMEWORK ......................................................................... 28

O padro de projeto Service API ........................................................................... 28

Estrutura do Pattern Service API ........................................................................... 29

Consumindo Webservice REST no Android........................................................... 32

Funcionalidades do Framework ............................................................................. 33

Arquitetura do projeto ............................................................................................ 34

Classes Principais ................................................................................................. 37

Banco de Dados .................................................................................................... 42

Estrutura do Banco de Dados ......................................................................... 43

Exemplos bsicos: ................................................................................................. 44

DESENVOLVENDO UMA APLICAO........................................................................ 72

CONSIDERAES FINAIS .......................................................................................... 76

A comunicao entre diferentes dispositivos e sistemas abre um grande parque para

Outra tecnologia que tem levado a conectividade e a mobilidade a outros patamares

Este trabalho prope um framework para o consumo de Webservice REST em

O consumo de Webservice REST na plataforma Android desenvolvido utilizando

Esses cdigos de infraestrutura e suporte referem-se lgica para controle

O reuso um conceito amplamente usado em engenharia de software, o

Referente ao consumo de Webservice na plataforma Android; esperado que nos

Sobre o modelo de arquitetura apresentada na hiptese de soluo deste trabalho,

O objetivo deste trabalho desenvolver um framework para consumo de Webservice

A hiptese levantada utilizar um framework que encapsule funes comuns no

Para o desenvolvimento deste trabalho, foi realizada uma pesquisa bibliogrfica a

O terceiro captulo apresenta o desenvolvimento de um framework para o consumo

O quinto captulo contm as consideraes finais, resultados obtidos e proposies

Engenharia de software baseada em reuso uma abordagem de desenvolvimento

produo, mais confivel do que um

desenvolvimento sejam sempre uma

projetos, pois reduz a margem de erro

e mais, estes especialistas de aplicativos

padro de componentes reutilizveis.

usando componentes reutilizveis, todas

mesmos formatos de menu para os

pode acelerar o sistema de produo

Ao longo dos anos, muitas tcnicas de desenvolvimento baseado em reuso foram

Desenvolvimento baseado em componentes e frameworks (SOMMERVILLE, 2007).

Um componente elemento funcional de um programa que incorpora a lgica e

Um framework um conjunto de classes que colaboram para realizar uma

O fato de que muitos sistemas de software contm componentes idnticos ou com

Como apresenta a figura 1, a interseco (mesma famlia de problemas) entre

Figura 1: Interseco de funes comuns entre sistemas distintos.

Fonte: (SAUV, 2011, s. p)

Em um cenrio em que h a interao, entre diferentes empresas que precisam