You are on page 1of 18

WEB SERVICE REST EM JAVA COM JAX-RS

Edilson Hipolito da Silva1 Edson Mundin Ferreira2


1

Faculdade Integrado de Campo Mouro.

Av irmos Pereira 670 Campo

Mouro PR, Brasil. E-mail: edilsonhipolito@gmail.com


2

UEPR Universidade Estadual do Paran. Av Gabriel Esperidio S/N

Paranava PR, Brasil. E-mail: edson@mundin.com.br

RESUMO

A necessidade de troca de informaes entre diferentes softwares, os quais normalmente utilizam tecnologias diferentes, vem crescendo muito com a dinmica do mercado. Pensando em solucionar este problema surgiram os Web Services. certo que h vrios tipos de Web Services e muitas linguagens de programao que suportam sua implementao, mas optouse por apresentar o Web Service do tipo REST, por ser uma tecnologia nova no mercado que pode auxiliar muitos desenvolvedores em suas integraes, e a linguagem de programao Java, base para a aplicao do Web Service REST, j consolidada no mercado e bem aceita entre os desenvolvedores. Palavras Chaves : REST; RESTful; Java; Web Service; JAX-RS, HTTP.

ABSTRACT

The need for exchange information between different software, which often use different technologies, has been increasing with the market dynamics. Thinking of solving this problem emerged Web. Admittedly, there are many types of Web services and many programming languages that support its implementation, but we chose to present the REST Web Service type, being a new technology on the market that can help many developers in their integration, and language Java programming, the basis for implementing the Web Service REST, is already established market and well accepted among developers. Keywords : REST, RESTful, Java, Web Service, JAX-RS, HTTP.

INTRODUO

Com a evoluo do modelo de negcio das empresas, tornando-se cada vez mais evidente e necessrio o comercio eletrnico no dia-a-dia, surge a necessidade de desenvolver uma ferramenta que permite a comunicao entres diferentes softwares, podendo estes serem desenvolvidos em uma mesma plataforma, linguagem de programao, criados pela mesma empresa, ou totalmente distintos, feitos em plataforma, linguagens e por empresas diferentes, como ocorre com a relao cliente e fornecedor. Moro et al. (s.d.) define Web Service como Um Web Service um sistema de software desenvolvido para suportar interoperabilidade entre maquinas sobre uma rede... Para suprir esta necessidade de comunicao que surgiram os Web Services. Pode-se definir Web Services como softwares que efetuam a comunicao entre diferentes softwares de forma transparente entre os mesmos. Atualmente existem vrios tipos de Web Services, dentre eles podemos citar os dois mais populares, WS-* e REST. Os Web Services vieram para suprir a alta demanda das empresas na troca de informaes, fazendo assim com que os mesmos fossem fortemente explorados nestes ltimos tempos. Com isso a cada dia surgem novas tecnologias e formas diferentes de implementao, mas um estilo de Web Service que est ganhando destaque por sua simplicidade e confiabilidade de implementao e utilizao o Representational State Transfer (REST), que faz uso extenso dos recursos HTTP (Hypertext Transfer Protocol) oferecendo aos usurios e desenvolvedores mais agilidade, facilidade no uso e tambm permitindo a construo de aplicaes mais leves e com alta performance segundo Santos (2009). Sero apresentados alguns exemplos de implementao em Java deste tipo de Web Service, juntamente com seus pontos positivos e negativos, sendo assim possvel analisar a possibilidade de sua utilizao. Prope-se tambm demonstrar a simplicidade de manipulao do mesmo, o que o fez to popular atualmente, e o que est fazendo o mesmo ganhar fora no mercado.

JAVA

Java uma linguagem de programao e uma plataforma de computao lanada pela primeira vez pela Sun Microsystems em 1995. a tecnologia que capacita muitos programas da mais alta qualidade, como utilitrios, jogos e aplicativos corporativos, entre muitos outros. O Java executado em mais de 850 milhes de computadores pessoais e em bilhes de dispositivos em todo o mundo, inclusive telefones celulares e dispositivos de televiso (SUN Microsystems, 2011). Sierra e Bates (2005) afirmam que Java seduziu os programadores com sua sintaxe amigvel, recursos orientados a objetos, gerenciamento de memria e, o melhor de tudo - a promessa de portabilidade. Sistemas Java geralmente so compostos de vrias partes: ambiente, linguagem, interface de programas aplicativos (API - Applications Programming Interface) Java e diversas bibliotecas de classes (M. DEITEL e J. DEITEL, 2003).

WEB SERVICE

Web Service um tipo de aplicao web que tem por finalidade facilitar a comunicao entre aplicaes de plataformas distintas, que utilizam objetos e linguagens distintas. Isto trs uma grande vantagem pois reduz grande parte dos problemas que teramos se fossemos efetuar uma comunicao direta entre uma plataforma e outra. Segundo Menndez (2002), h uma definio bastante simples para um Web Services: uma aplicao que aceita solicitaes de outros sistemas atravs da Internet. Segundo Snell (2001), Web Services so interfaces acessveis de rede, para as funcionalidades da aplicao, que utilizam em sua construo tecnologias padres da Internet. Com estas duas definies pode-se dizer que Web Services so servios que proporcionam a troca de informaes entre aplicaes web de forma transparente.

REST

O termo REST, originou-se no ano de 2000, atravs da tese de doutorado escrita por Roy Fielding (um dos principais autores da especificao HTTP), para descrever um estilo de arquitetura de softwares para sistemas hipermdias distribudos. Em sua tese Fielding (2000) diz que The name Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use. 1(FIELDING, 2000, P.109). REST representa um modelo de como a Internet deve funcionar. Muitas pessoas confundem REST como sendo um padro ou uma tecnologia, mas isso no verdade, no existindo nem mesmo uma entidade que efetue sua padronizao. Voc no ver a W3C (World Wide Web Consortium - organizao que padroniza os formatos da Web) publicando especificaes para REST, muito menos a IBM, Microsoft ou a Sun vendendo kit de ferramentas para o desenvolvedor REST. Isso acontece pelo simples fato de que, REST um estilo de arquitetura, isto , um conjunto de regras de design que definem quais os recursos, componentes e conectores que podem ser usados para compor um sistema, conforme cita Fielding (2011) em sua dissertao. No se pode definir um estilo como sendo um padro, simplesmente se entende um estilo, e ento poder desenhar seus Web Services para seguir este estilo. Dentre muitas caractersticas apresentamos as que consideramos de maior importncia para o desenvolvedor. Como primeira podemos citar o foco nos recursos. Filho e Ferreira (2009) definem recurso como ... uma abstrao ou conceito relevante que existe no domnio tratado pelo servio em questo... Adicionalmente, um recurso pode compreender um grupo de objetos... (2009, p. 37;38). Estes recursos so identificados atravs de suas URIs (Uniform Resource Identifier) nicas. Uma URI uma cadeia de caracteres compacta usada para identificar ou denominar um recurso. A sintaxe da URI um nome de conjunto acrescido de dois pontos, como por exemplo HTTP:.

A REST (Transferncia do Estado Representacional) pretendida como uma imagem do design da aplicao se comportar: uma rede de websites (um estado virtual), onde o usurio progride com uma aplicao selecionando as ligaes (transies do estado), tendo como resultado a pgina seguinte (que representa o estado seguinte da aplicao) que est sendo transferida ao usurio e apresentada para seu uso. (Traduo por Silveira e Andreis. Uma Anlise Comparativa entre REST e SOAP)

Outro ponto que chama ateno o fato de ser uma aplicao sem estado (stateless). Servios sem estado so aqueles cujas requisies acontecem em total isolamento, o consumidor do servio envia todas as informaes necessrias para a correta execuo de um determinado mtodo. Isto acontece em todos os momentos em que o mtodo solicitado (RICHARDSON; RUBY, 2007). Porem este tipo de estilo tambm traz algumas desvantagens como citado por Polnia e Silvestre (2008) "...redundncia dos dados que precisam ser enviados novamente a cada requisio e a reduo do controle por parte do servidor do funcionamento correto da aplicao, pois o cliente que efetua o controle do estado da aplicao. Em REST isso possvel atravs da transferncia de representaes de recursos, ao invs de operar diretamente sobre estes recursos. Destaca-se tambm, que seus recursos so todos acessados por meio de uma interface genrica, como por exemplo, o HTTP. Este protocolo oferece cinco mtodos principais para acesso aos recursos: GET, HEAD, POST, PUT e DELETE. Como citado anteriormente, todos estes mtodos proporcionam acessos aos recursos, permitindo assim a existncia de uma interface uniforme. Esta interface uniforme de o acesso aos recursos um conjunto de operaes pr-definidas, a qual permite que qualquer requisitante ao recurso entenda a operao solicitada. Por exemplo, quando temos a URI http://sample.com/orders/10, se efetuarmos uma requisio esta URI, do tipo GET, obtm-se os detalhes do pedido nmero 10, se for uma requisio do tipo PUT ou POST, estaria atualizando ou inserindo dados a um pedido, j se for uma requisio do tipo DELETE, poderamos estar cancelando ou excluindo um pedido. Com tudo Tobaldini (2007) diz que o grande problema desta interface uniforme que toda a troca de informao feita de uma forma genrica ao invs de ser especfica para cada necessidade.. Porem Tobaldini (2007) tambm afirma que REST foi projetado para ser eficiente na troca de dados hipermdia no caso, comum, a WEB.. A manipulao dos dados feita atravs de mtodos Request e Response, que recebem e enviam informaes ao solicitante. Como exemplo de servidores que recebem os Request dos clientes, podemos citar: Tomcat, GlassFish, JBoss entre outros. J os clientes que consomem estes Web Services e recebem os Response do servidor temos como exemplo os prprios navegadores WEB, e at softwares desenvolvidos por terceiros. Outra caracterstica importante o suporte a todos os MIME Types (XML, TextPlain, Json, Atom, etc), que podem ser acessados atravs de mtodos HTTP respeitando sua interface uniforme. Para fazer os acesso aos dados, REST baseia-se na extensa explorao dos recursos HTTP (POST, GET, PUT E DELETE), que so utilizados para criar, retornar, alterar e excluir conforme quadro 1. As respostas das requisies so retornadas atravs de cdigos de
5

status dos mtodos HTTP, conforme quadro 2, que apresenta os cdigos de respostas clssicos do HTTP.

Mtodo GET PUT DELETE POST

Descrio Solicita que o servidor envie um recurso. O inverso do GET. Realiza operaes de escrita no servidor. Solicita a excluso de um recurso no servidor. Foi projetado para o envio de dados de input, por exemplo, os dados de um formulrio.

HEAD

Mesmo comportamento que o mtodo GET, porm o servidor retorna apenas o cabealho da resposta.
Quadro 1: Mtodos HTTP mais comuns. Fonte: Santos (2009)

Range 100-101 200-206 300-305 400-415 500-505

Descrio Informacional. Sucesso. Redirecionamento. Erro do Cliente. Erro do Servidor.


Fonte: Santos (2009)

Quadro 2: Cdigos de status HTTP segmentados em categorias.

REST faz extenso uso dos recursos HTTP, e quando se trata de manipulao de dados geralmente esses recursos so combinados com operaes CRUD (Create, Read, Update, e Delete), para efetuar a persistncia e recuperao dos dados (Conforme quadro 3), mas isso no uma regra, podero existir casos em que no exista o mapeamento do tipo HTTP/CRUD.

Mtodos HTTP GET POST PUT DELETE

Operaes CRUD SELECT INSERT, UPDATE, DELETE CREATE, UPDATE DELETE


Fonte: Santos (2009)

Quadro 3: Associao dos mtodos HTTP com operaes CRUD

Para um melhor entendimento do mapeamento dos mtodos HTTP com operaes CRUD, temos como exemplo a URI http://sample.com/orders/10, que responde ao recurso dos pedidos, e tem um mapeamento HTTP/CRUD, onde se podem efetuar requisies HTTP de diversos tipos. Quando esta URI receber uma requisio do tipo GET devido ao seu mapeamento HTTP/CRUD, ela ir devolver os dados do pedido numero 10, se ao invs de GET a requisio for do tipo POST, ento ser adicionado um novo pedido, no caso do DELETE, estar excluindo um pedido, e assim acontece com os demais mtodos HTTP. Quando se faz acesso a um recurso em REST geralmente o faz por meio de uma URI, esta definida por meio de uma sintaxe universal sendo que uma das regras desta sintaxe o fato da URI ser nica, apontando somente para um determinado recurso. O uso de URI, facilitar a outros desenvolvedores que querem consumir o Web Service, pelo fato da mesma ser um endereo limpo e claro, conforme exemplo abaixo:

Mtodo comum: http://sample/service?type=recupera&pedido=2029 Mtodo com URI: http://sample.com/service/pedido/2029 Pode-se perceber neste exemplo que ao utilizar URI ao invs de passar inmeros

cdigos e parmetros no endereo, indicam-se os servios de forma simples e direta, facilitando assim seu acesso. Ainda no exemplo acima se pode notar o acesso a um pedido, cujo nmero 2029, o Web Service ir devolver uma resposta que poder vir em HTML, XML, JSON, etc. O formato desta resposta depende da implementao feita no servidor. Ao fazer Request/Response um Web Service do tipo REST, isto , fazer uma requisio e receber um Web Service REST, o mesmo recebe e responde apenas o necessrio ao seu solicitante, isto trs uma melhor performance se comparado com outros Web Services, pelo fato dos dados no precisarem estar envelopados dentro de um pacote SOAP para que a troca de informaes ocorra.

METODOLOGIA

Essa pesquisa caracteriza-se como sendo do tipo exploratria. O carter exploratrio ocorre com os levantamentos bibliogrficos de outros autores que discorrem sobre o assunto, alm da anlise de exemplos, grficos e matrias que estimulam a compreenso do Web Service do tipo REST, e tambm a respeito da tecnologia JAVA. Para Aaker, Kumar e Day (2001, p.94) a pesquisa exploratria usada quando se busca o entendimento sobre a natureza geral de um problema. No mesmo raciocnio, Churchill e Petter (2003, p.126) frisa que quando os pesquisadores procuram descobrir ideias e percepes, eles conduzem uma pesquisa exploratria. Seguindo este raciocnio a pesquisa se torna explorativa, devido a problemtica de como implementar um Web Service do tipo REST em Java.

REST e API JAX-RS

REST representado em Java atravs da API JAX-RS, que provem da especificao JSR3112, e liberada ao pblico em agosto de 2008. Esta especificao define um conjunto de APIs Java que auxiliam o desenvolvimento de Web Services do tipo REST. JAX-RS um modelo baseado em anotaes, onde se definido uma URI para o acesso ao recurso, que por sua vez define uma mapeamento entre uma URI e uma classe Java. Como citado anteriormente JAX-RS faz uso de anotaes, com isso podemos destacar como uma das suas anotaes e de maior importncia o @Path, que utilizada para definir quando uma classe pode ser acessada como um recurso, ou seja, esta tag responsvel por efetuar o mapeamento entre a URI e classe Java. A anotao @Path pode ser inserida na declarao da classe, ou na declarao de um mtodo, trazendo um parmetro obrigatrio que indica a URI, a qual a classe ou mtodo ir responder. Geralmente quando se adiciona a anotao @Path em um mtodo, estamos atribuindo um caminho mais especifico para um determinado recurso, permitindo o acesso direto a um determinado recurso. Na figura 1 podese observar que o mapeamento URI feito atravs da anotao @Path em que a classe Aluno
2

JSR311. Disponvel em: <http://jsr311.java.net/> Acessado em 14/06/2011.

atende ao recurso atravs da URI /aluno, e o mtodo getNotas, atravs da URI /aluno/notas, assim pode-se notar que quando acessado a URI /aluno/notas est se fazendo uma requisio direta ao mtodo getNotas que retornar as notas do aluno, e ao fazer acesso a URI /aluno, acessa-se a classe onde sero retornados todos os dados do aluno.

Figura 1: Mapeamento URI com a anotao @Path Fonte: desenvolvido pelos autores

Para acessar os recursos e manipular seus dados, utiliza-se os mtodos HTTP, como citado anteriormente, no JAX-RS contamos com as anotaes: @Get, @Post, @Put, @Delete, que indicam a qual tipo de requisio HTTP o recurso responder, tambm necessrio observar que para acessar os mtodos da classe Java, atravs das URIs, os mesmos devem ser declarados como pblicos, por exemplo, quando adiciona-se a anotao @Get um mtodo, permite-se o acesso aos dados atravs de requisies do tipo GET, ou seja o mesmo responder requisies HTTP do tipo Get (observe a figura 2), se a anotao for @Post responder requisies HTTP do tipo Post, e assim sucessivamente acontece com todos os mtodos HTTP, com isso pode-se dizer que o comportamento do recurso se deve ao tipo de mtodo HTTP ao qual ele responder.

Figura 2: URI respondendo a uma requisio HTTP do tipo GET Fonte: desenvolvido pelos autores

Ao combinar os principais tipos de requisies HTTP com operaes CRUD, faz-se um mapeamento do tipo HTTP/CRUD, em Java isso feito atravs da API JAX-RS que faz uso de suas anotaes para manipular as requisies HTTP. Na figura 3, h um exemplo de um mapeamento entre os mtodos HTTP e as operaes CRUD, onde exemplificamos o uso de cada uma das requisies HTTP. Ao analisar a URI http://escola.com/classe/alunos chega-se a concluso que se est acessando um recurso do tipo GET que retorna todos os alunos, mas observando esta URI http://escola.com/classe/alunos/136, ser preciso analisar qual o tipo do mtodo HTTP utilizado para fazer acesso ao recurso, pois se estiver utilizando o GET, estar recuperando os dados de um nico aluno, neste caso o aluno de cdigo 136, quando se usa o PUT, acessa-se o mtodo responsvel por realizar a atualizao dos dados do aluno informando como parmetro do mtodo o id do aluno, e por fim ao utilizar o DELETE, acessa-se o mtodo responsvel por remover um aluno da classe, da mesma forma como nos mtodos anteriores informa-se por parmetro o id do aluno.

Figura 3: Mapeamento HTTP/CRUD Fonte: desenvolvido pelos autores

10

Alm de permitir o acesso aos recursos necessrio definir quais sero os formatos aceitos durante os Request e Response ao servidor. Estes formatos so definidos atravs das anotaes @Consumes, e @Produces, que podem ser inseridas na declarao da classe ou na declarao de um mtodo, neste caso ir sobrescrever a declarao feita na classe. Com o uso destas anotaes definido qual ser o tipo do contedo trafegado atravs do cabealho (header) do protocolo HTTP. Quando feita uma requisio ao servidor e o mesmo devolve uma resposta, esta ser no formato definido atravs da anotao @Produces, que suporta todos os tipos MIME do protocolo HTTP ("text/plain", "text/html", "application/xml", "application/json", etc). Podese definir mais que um tipo possvel de retorno, ou simplesmente no definir nenhum formato, assim ser assumido o padro que representa qualquer tipo de retorno (*/*). Como se pode observar na figura 4, a classe define o formato de retorno como sendo text/plain, mas o mtodo getAlunos, sobrescreve este formato oferecendo dois novos tipos de retorno: "application/xml", "application/json".

Figura 4: Tipos de response com a anotao @Produces Fonte: desenvolvido pelos autores

J com a anotao @Consumes definido quais os formatos que o recurso ir consumir, seguindo os mesmos padres aplicados anotao @Produces. Conforme se observa na figura 5 o mtodo addAluno consome apenas o formato XML.

11

Figura 5: @Consume, tipo de formato a ser consumido Fonte: desenvolvido pelos autores

Alm das anotaes citadas anteriormente, tambm h uma srie de outras anotaes que auxiliam de diversas formas, dentre elas pode-se citar, @PathParam, que auxilia na extrao de informaes de um requisio HTTP, e pode ser aplicada diretamente a parmetros de um mtodo conforme mostra figura 6, tambm h a anotao @FormParam utilizada para capturar os valores submetidos a um formulrio HTML, e assim transporta-los para parmetros desejados, conforme v-se na figura 7, tambm a @QueryParam que utilizada para extrair o valor de um parmetro indicado na query, e atribui-lo a um parmetro ou atributo da classe, conforme observa-se na figura 8, e por ltimo tem a anotao

@HeaderParam, utilizada para extrair valores header HTTP, e associa-los a um parmetro ou mtodo, o qual pode ter diversas aplicaes, como verificar qual browser est sendo utilizado, o sistema operacional que est efetuando o acesso, etc. Na figura 9 possvel ver um exemplo de utilizao do @HeaderParam.

Figura 6: @PathParam Fonte: desenvolvido pelos autores

12

Figura 7: @FormParam - capturando dados do formulrio Fonte: desenvolvido pelos autores

Figura 8: @QueryParam - recuperando um valor da query Fonte: desenvolvido pelos autores

Figura 9: @HeaderParam - Acessando dados do header, verificando o browser utilizado Fonte: desenvolvido pelos autores

Outra parte importante, e que auxilia muito no desenvolvimento de aplicaes, o tratamento de excees, que em JAX-RS identificada pela anotao

@WebApplicationException. As excees em JAX-RS estendem as excees bsicas de Java, ou seja, estendem a classe RunTimeException. Quando definida uma exceo do tipo WebApplicationException retornado um cdigo de erro HTTP e uma mensagem, por padro este cdigo de erro enviado ao cliente o HTTP 500, e a mensagem devolvida em branco, mas tambm possvel alterar o tipo do erro enviado na forma de parmetro do mtodo, e tambm a mensagem retornada ao cliente que est efetuando o acesso ao servio. Na figura 10 h um exemplo de utilizao do WebApplicationException que devolve um cdigo de erro HTTP 405.

13

Figura 10: WebApplicationException Fonte: desenvolvido pelos autores

As anotaes e exemplos citados so os considerados de maior importncia e o princpio para aquele que deseja iniciar o seu estudo sobre REST. Mas alm destas existem muitas outras anotaes e recursos, disponveis ao desenvolvedor, como os clientes de acesso ao REST, que no foram abordados neste artigo devido a sua extenso.

CONCLUSO

Neste artigo procurou-se abordar uma viso geral sobre Web Services e principalmente o uso do Web Service do tipo REST em Java, proporcionando desde conhecimentos iniciais aos Web Services, para que o leitor possa entender como funciona este recurso, e despertar o interesse de estudo do mesmo. Da mesma forma para aqueles que j tm conhecimento, em Web Services em outras linguagens de programao, possam iniciar seus estudos em Web Services do tipo REST em Java. Foram exemplificadas algumas formas de implementao e utilizao do JAX-RS, mas h que se ressaltar que existem outras maneiras de implementao do mesmo, portanto no se pode considerar a nica ou a melhor forma de implementao, mas sim uma das formas possveis de se implementar REST em Java, tendo em vista que a melhor forma aquela que atende as necessidades do desenvolvedor para aquela aplicao em especfico. Diante dos exemplos apresentados, e referencial terico levantado neste trabalho que nos mostra as qualidades e defeitos de se utilizar REST, podemos observar que possvel e relativamente simples a implementao de Web Service do tipo REST em Java, tendo em
14

vista a sua grande explorao dos recursos HTTP e o uso da API Jax-RS, que faz uso de anotaes que proporcionam ao desenvolvedor uma maior facilidade e agilidade no desenvolvimento dos Web Service. Tambm foi possvel contemplar que REST se destaca por sua velocidade, graas a utilizao de recursos j existentes, como os que existem no HTTP (Get, Post, Put e Delete), seus dados no precisam ser envelopados dentro de pacotes SOAP para transmisso, como ocorrem com outros tipos de Web Service (Santos 2009). Como dito anteriormente REST faz extenso uso dos recursos HTTP, e isto facilita tambm para aqueles que iro consumir o Web Service, pois j esto acostumados com o mtodos HTTP (Get, Post, Put e Delete) e iro conseguir de maneira mais simples consumir os recursos proporcionados pelo Web Service. Devido a estas caractersticas REST vem ganhando muita fora de mercado e atraindo cada vez mais desenvolvedores , um bom exemplo disto a amazon que disponibiliza Web Services nos dois estilos (REST e SOAP), mas 85% da utilizao se d atravs da interface SOAP (Tim OReilly 2003).

REFERNCIAS

SANTOS, Wagner Roberto dos, RESTful Web Services e a API JAX-RS. Mundo Java ed. 35, Ano VI - Maro/Abril 2009.

SILVA, Bruno Luiz Pereira da. REST vs WS-* Uma viso pragmtica. Java Magazine ed. 54 ano VI.

SILVA, Bruno Luiz Pereira da; MEDEIROS, Alexandre Bairos. Web services REST Uma abordagem prtica. Java Magazine ed. 56 ano VI.

15

CAVALCANTI, Marcus . Web Services: REST versus WS-*, WS-* versus REST. Disponivel em: <http://www.marcuscavalcanti.net/blog/2009/04/13/webservices-RESTversus-ws-soap/>. Acessado em 31 maro 2010.

TYAGI, Sammer. RESTful Web Services. Disponivel em: <http://www.oracle.com/technetwork/articles/javase/index-137171.html>. Acessado em 15 julho 2010.

SANDOZ, Paul, PODLESAK, Jakub. Implementing RESTful Web Services in Java. Disponivel em: <http://blogs.sun.com/enterprisetechtips/entry/implementing_RESTful_web_services_in>. Acessado em 28 agosto 2010.

JUNIOR, Sergio Azevedo. Arquitetura REST com Java: JAX-RS. Disponivel em: <http://blog.caelum.com.br/2009/12/15/arquitetura-REST-com-java-jax-rs/>. Acessado em 18 maro 2010.

VELLOSO, Fabio. RESTful Web Services em Java. Disponivel em: <http://tv.softwarelivre.org/video/RESTful-web-services-em-java/>. Acessado em 14 outubro 2010.

SANTOS, Wagner Roberto dos. Web Services WS-* vs REST. Disponivel em: <http://netfeijao.blogspot.com/2009/05/web-services-ws-vs-REST.html/>. Acessado em 15 julho 2010.

16

SILVA, Bruno Luiz Pereira. Web Services REST. Disponivel em: <http://www.linhadecodigo.com.br/Artigo.aspx?id=2059&pag=2>. Acessado em 18 maro 2010.

AAKER, D. A, KUMAR, V, DAY, G. S. Pesquisa de Marketing. 6a ed. So Paulo, Atlas, 2001.

SILVESTRE, Erich; POLNIA, Pablo Valrio. Uma Aplicao da Arquitetura Orientada a Recursos, 2008.

TOBALDINI, Ricardo Ghisi. Arquitetura REST: um estudo de sua implementao em linguagens de programao, 2007.

MORO, Tharcis Dal, DORNELES, Carina Friedrich . Rebonatto, Marcelo Trindade. Web services WS-* versus web Services REST, s.d. CHURCHILL, G. A. Marketing: criando valor para os clientes. 2a ed. So Paulo, Saraiva, 2003.

FILHO, Otvio Freitas Ferreira; FERREIRA, Maria Alice Grigas Varella. Servios semnticos: Uma abordagem RESTful. Conferncia IADIS Ibero-Americana WWW/Internet 2009. p. 37-8.

SUN Microsystems. Disponivel em: <http://www.java.com/>. Acessado em 14 abril 2011.

SIERRA, Kathy; BATES, Bert, Use a Cabea! Java. 2a ed. Rio de Janeiro, Alta Books,

17

2005. 470 p.

M. DEITEL, Harvey.; J. DEITEL, Paul. Java como Programar. 4a ed. Porto Alegre. Bookman. 2003. 1386 p.

MENNDEZ, Andrs Igncio Martnez. Uma ferramenta de apoio ao desenvolvimento de Web Services. Dissertao de Mestrado, Universidade Federal de Campina Grande, curso de Ps-Graduao em Informtica, 2002. 97 p.

SNELL, James. Programming Web Services with SOAP. Sebastopol: O'Reilly, 2001. 216p.

FIELDING, R. T.; Architectural Styles and the Design of Network-based Software Architectures, Universidade da Califrnia, 2000. Disponvel em: <http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>

RICHARDSON, L.; RUBY, S., 2007. RESTful Web Services. OReilly Media, Sebastopol, USA.

OReilly, T. REST vs. SOAP at Amazon. Disponvel em: <http://www.oreillynet.com/pub/wlg/3005 >. Acessado em 20 maro 2011.

18

You might also like