Ricardo R. Lecheta
Novatec
Copyright © 2015 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora. Editor: Rubens Prates Assistente editorial: Priscila A. Yoshimatsu Revisão gramatical: Marta Almeida de Sá Editoração eletrônica: Carolina Kuwabata Capa: Carolina Kuwabata ISBN: 978-85-7522-454-0 YG20150903 Histórico de impressões: Setembro/2015
Primeira edição
Novatec Editora Ltda. Rua Luís Antônio dos Santos 110 02460-000 – São Paulo, SP – Brasil Tel.: +55 11 2959-6529 Email: novatec@novatec.com.br Site: novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec
capítulo 1
Introdução
1.1 Introdução Construção de web services e computação em nuvem são os dois pilares mais importantes no mundo do desenvolvimento de sistemas, e o objetivo deste livro é abordar ambos os conceitos de forma prática. Durante a leitura do livro, vamos construir uma aplicação servidora completa utilizando web services RESTful com Java e alguns dos frameworks líderes de mercado, como Hibernate, Spring e Jersey. Também vamos aprender a instalar a aplicação na plataforma de computação em nuvem do Google chamada Google Cloud Platform. Com isso você vai aprender como configurar servidores web e bancos de dados na nuvem e gerenciar seu próprio datacenter. Por último, teremos exemplos de aplicações clientes que consomem os web services criados neste livro. Veremos um sistema web construído em AngularJS e um aplicativo para Android.
1.2 Tecnologias utilizadas no livro Neste livro vamos utilizar a linguagem Java e alguns dos frameworks líderes de mercado para construir os web services. Java é uma linguagem de programação lançada pela Sun Microsystems em 1995, também conhecida como plataforma Java, graças ao grande número de frameworks, servidores e tecnologias por trás de toda a plataforma. A princípio não é obrigatório que você já domine a linguagem, mas, se souber o básico, será mais fácil acompanhar as explicações. Todos os capítulos apresentam 17
18
Web services RESTful
exemplos de código passo a passo, portanto, mesmo que você não domine a linguagem, não terá problemas. Alguns dos frameworks ou das tecnologias que vamos utilizar durante o livro são:
Maven Sistema de gerenciamento de builds que facilita o controle das dependências e a compilação do projeto. Hibernate Popular framework ORM (Object Relational Mapping), que facilita a persistência de objetos em um banco de dados relacional. Spring Consagrado framework no mundo Java. É muito utilizado para controlar e organizar a camada de negócios do sistema, e um de seus grandes benéficos é que ele se integra e facilita a utilização de vários frameworks Java populares do mercado. Jersey Framework oficial da Sun/Oracle que implementa a especificação API for RESTful Services (JAX-RS), a qual define como devem funcionar web services RESTful em Java. Google Cloud Platform Vamos estudar como instalar a aplicação com web services na nuvem do Google. Segurança e OAuth O livro contém três capítulos sobre segurança em web services, inclusive sobre OAuth, que é uma especificação criada para fornecer acesso seguro aos sites, principalmente quando temos que integrar diferentes sistemas. AngularJS Biblioteca JavaScript de código aberto mantida pelo Google. No livro, vamos estudar uma aplicação web completa em AngularJS. Android Sistema operacional móvel mais utilizado no mundo. Depois de construir os web services do livro, vamos ver um exemplo de aplicativo que utiliza estes web services.
19
Capítulo 1 ■ Introdução
1.3 Web services Web services são utilizados como forma de integração e comunicação de sistemas, de modo que um sistema possa realizar uma chamada para um serviço de outro sistema a fim de obter informações. Estas chamadas podem enviar e receber informações em diversos formatos, sendo que atualmente os mais populares são XML e JSON. Uma das grandes vantagens na construção de web services é que eles permitem acessar os serviços de uma forma padronizada e independente de linguagem de programação. Por exemplo, é possível escrever um web service com a linguagem Java, mas consumi-lo em qualquer outra linguagem, como C#, PHP, Python etc. Este conceito trouxe um grande avanço na forma que os sistemas são construídos, pois permite separar e quebrar o sistema em partes. Existem várias formas de criar web services, mas podemos dizer que duas das mais conhecidas são web services em SOAP ou REST.
1.4 Web services SOAP O SOAP é um protocolo de comunicação de web services descrito por uma WSDL (Web Services Description Language). Na prática, o SOAP é um grande arquivo XML trafegado entre os sistemas para fazer a comunicação. Para você entender na prática o que é SOAP, vamos brincar com um web service gratuito utilizado para retornar informações de clima e tempo para determinada cidade. Para isso, acesse o link: http://www.webservicex.net/globalweather.asmx Ao abrir essa página, você verá dois serviços: GetCitiesByCountry e GetWeather, conforme mostra a figura 1.1. Se você clicar em algum deles, será aberta uma página de testes com informações sobre cada serviço.
Figura 1.1 – Web service de tempo.
20
Web services RESTful
Na página mostrada pela figura 1.1, caso clique no link Service Description, você verá a WSDL (Web Services Description Language) deste web service, que é um grande XML que descreve todos os métodos disponíveis neste serviço, ou seja, os métodos que podemos chamar e executar. http://www.webservicex.net/globalweather.asmx?WSDL
Recomendo que você clique neste link e veja a WSDL. Com estas informações, qualquer sistema independente da linguagem de programação pode fazer chamadas nestes web services, pois neste arquivo está descrito exatamente como estas chamadas devem ser feitas. Agora, na primeira página do web service, clique em alguns dos serviços GetCitiesByCountry ou GetWeather para visualizar a página de testes. A figura 1.2. mostra a página de teste do serviço GetWeather. Este web service em específico foi feito em .NET. Isso é fácil de descobrir pela extensão da página, que é .asmx (ASP.NET). Embora este livro seja sobre Java, web services feitos em .NET geralmente contêm estas páginas que facilitam os testes, portanto também facilitam a explicação, por isso os estou utilizando como exemplo aqui. Na página de teste do web service, existe um formulário que, se você preencher e clicar no botão Invoke, ele vai disparar o web service via POST. Acredito que você possa fazer este teste, pois é bem intuitivo. Basta preencher o campo Cityname com o nome de uma cidade e digitar Brazil (com z) no campo Countryname. Mas o que quero lhe explicar agora é o protocolo SOAP (Simple Object Access Protocol), que consiste em uma mensagem no formato XML utilizada como entrada e saída de web services do tipo SOAP, descritos por uma WSDL. Na figura 1.2 há uma seta que aponta para esse XML em SOAP, apenas para você ver como é a estrutura. Ao rolar a página um pouco mais para baixo, podemos ver detalhadamente o formato da mensagem SOAP, conforme mostra a figura 1.3. A primeira parte da figura mostra a mensagem SOAP de entrada, e a segunda parte, a mensagem SOAP de saída. Isso significa que, se algum sistema precisar se comunicar com este web service, ele precisará fazer uma requisição HTTP do tipo POST nesta página passando este XML do protocolo SOAP como parâmetro. A resposta também será um grande XML no formato SOAP. Como o SOAP é um grande XML, ele começou a perder espaço para web services RESTful, que apresentam uma sintaxe mais enxuta e podem enviar e receber informações em formatos mais leves. Principalmente no mundo mobile, os aplicativos precisam economizar recursos ao trafegar informações, e justamente por isso o SOAP está perdendo espaço para o REST.
21
Capítulo 1 ■ Introdução
Figura 1.2 – Web service de tempo para uma cidade.
Figura 1.3 – Formato de uma mensagem SOAP.
22
Web services RESTful
1.5 Web services simples com HTTP Se explorarmos um pouco mais a página de exemplo do web service de tempo, veremos que, além do SOAP, este web service também pode ser chamado via POST ou GET. Sabemos disso, pois, ao rolar a página um pouco mais para baixo, veremos as informações sobre HTTP POST, conforme mostra a figura 1.4. Esta parte da página está informando que, se fizermos um POST na página /globalweather.asmx/GetWeather passando os parâmetros CityName=string&CountryName=string, poderemos obter o resultado. Isso é um recurso interessante destes web services escritos em .NET, pois eles podem escolher se habilitam os serviços a serem chamados apenas por SOAP ou se também permitem que os serviços sejam chamados por chamadas simples de POST ou GET.
Figura 1.4 – Formato do envio via POST.
No caso do formulário de exemplo (Figura 1.5), é exatamente uma chamada do tipo POST que ele faz, pois isso é um padrão de internet.
Figura 1.5 – Formulário via POST sendo preenchido.
23
Capítulo 1 ■ Introdução
Ao testar este formulário, ou seja, ao fazer uma requisição do tipo POST neste serviço, o retorno será um pequeno XML com as informações, conforme mostra a figura 1.6.
Figura 1.6 – Resultado do envio via POST.
Se formatarmos este XML, teremos a seguinte saída: <?xml version="1.0" encoding="UTF-8"?> <CurrentWeather> <Location>Curitiba Aeroporto , Brazil (SBCT) 25-31S 049-10W 908M</Location> <Time>Aug 02, 2015 - 11:00 AM EDT / 2015.08.02 1500 UTC</Time> <Wind>from the NW (310 degrees) at 13 MPH (11 KT):0</Wind> <Visibility>greater than 7 mile(s):0</Visibility> <Temperature>73 F (23 C)</Temperature> <DewPoint>42 F (6 C)</DewPoint> <RelativeHumidity>33%</RelativeHumidity> <Pressure>30.15 in. Hg (1021 hPa)</Pressure> <Status>Success</Status> </CurrentWeather>
O importante é você não confundir o que é o XML do SOAP com este XML de retorno. No caso do SOAP, o XML faz parte do protocolo. Ou seja, mesmo que o seu serviço tenha retornado uma simples linha ou um status de OK, o XML do protocolo SOAP precisou ser trafegado. Neste caso, o XML é utilizado apenas como formato de transferência e comunicação entre sistemas, pois os dados precisam ser expressos e visualizados de alguma forma. Para deixar claro, no caso do SOAP, a resposta deste web service seria mais ou menos assim:
24
Web services RESTful <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http:// www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <GetWeatherResponse xmlns="http://www.webserviceX.NET"> <GetWeatherResult> <CurrentWeather> <!-- XML DO TEMPO AQUI DENTRO. --> <CurrentWeather> </GetWeatherResult> </GetWeatherResponse> </soap:Body> </soap:Envelope>
Veja que o XML do tempo é o conteúdo da mensagem enviada por SOAP. Mas somente na mensagem em si temos diversas tags de XML, algo que torna esse formato um pouco extenso. Tanto para enviar as mensagens em SOAP quanto para ler o retorno é preciso decifrar estas tags de SOAP e entender o protocolo. Por causa dessa dificuldade, surgiram no mercado diversas ferramentas e frameworks com o objetivo de facilitar essa comunicação e o tráfego das mensagens em SOAP. Agora, voltaremos ao formato de retorno do web service, que é aquele XML que contém a tag <CurrentWeather> com as informações do tempo. Este formato de retorno pode ser qualquer coisa que você ou algum sistema consiga entender. Outro formato bastante popular atualmente, o qual vamos utilizar no livro, é o JSON. Se convertêssemos o XML de retorno do web service do tempo para JSON, teríamos a seguinte saída. Se comparado ao XML, o JSON é mais enxuto e seu formato é menor, pois ele não precisa sempre abrir e fechar as tags. O JSON nada mais é do que um objeto ou uma estrutura de dados representada em JavaScript. { "CurrentWeather": { "Location": "Curitiba Aeroporto , Brazil (SBCT) 25-31S 049-10W 908M", "Time": "Aug 02, 2015 - 11:00 AM EDT / 2015.08.02 1500 UTC", "Wind": "from the NW (310 degrees) at 13 MPH (11 KT):0", "Visibility": "greater than 7 mile(s):0", "Temperature": "73 F (23 C)", "DewPoint": "42 F (6 C)", "RelativeHumidity": "33%", "Pressure": "30.15 in. Hg (1021 hPa)", "Status": "Success" } }
25
Capítulo 1 ■ Introdução
O JSON anterior está formatado com quebras de linhas para facilitar sua visualização, mas muitas vezes os sistemas retornam o JSON compactado em uma única linha, conforme demonstrado a seguir: {"CurrentWeather":{"Location":"Curitiba Aeroporto , Brazil (SBCT) 2531S 049-10W 908M","Time":"Aug 02, 2015 - 11:00 AM EDT / 2015.08.02 1500 UTC","Wind":"from the NW (310 degrees) at 13 MPH (11 KT):0","Visibility":"greater than 7 mile(s):0","Temperature":"73 F (23 C)","DewPoint":"42 F (6 C)","RelativeHumidity":"33%","Pressure":"30.15 in. Hg (1021 hPa)","Status":"Success"}}
Isso torna o resultado bem enxuto e diminui o tráfego de informações na rede, algo vital principalmente em aplicativos para dispositivos móveis. Para encerrar esta seção, sempre que fazemos requisições HTTP, podemos fazer via GET ou POST. A figura 1.7 mostra outra forma de fazer a chamada para este mesmo web service do tempo.
Figura 1.7 – Formato do envio via GET.
Conforme estas orientações, o serviço do tempo pode ser chamado, e os parâmetros podem ser passados diretamente na URL (por isso chama-se GET). Sendo assim, podemos chamar este serviço com esta URL: http://www.webservicex.net/ globalweather.asmx/GetWeather?CityName=Curitiba&CountryName=Brazil
A figura 1.8 mostra o resultado desta chamada, que é o mesmo XML de retorno que tivemos ao fazer a chamada via POST. A diferença é que o POST envia os dados no corpo da requisição (de forma oculta para o usuário) e pode enviar uma grande quantidade de informações, inclusive fazer upload de arquivos. Já o envio por GET é limitado, pois passa os parâmetros na URL e deve ser utilizado geralmente em web services simples de consulta.
26
Web services RESTful
Figura 1.8 – Resultado do envio via POST.
1.6 Web services RESTful Vimos que o exemplo de web service do tempo citado nas explicações pode ser chamado de duas formas. A primeira é utilizando o protocolo SOAP, o qual nem testamos, pois seria necessário escrever algum código que enviasse e recebesse os dados neste formato. A segunda utiliza um modelo simples de requisições baseadas no protocolo HTTP, e vimos que podemos fazer chamadas por GET ou POST. Lembrando que este exemplo foi possível, pois estes web services escritos em .NET nos fornecem todas estas possibilidades de chamada, por isso escolhi este exemplo para explicar os conceitos. Mas o que é REST? O Representational State Transfer (REST) é uma técnica de desenvolvimento de web services fortemente baseada nos métodos do protocolo HTTP (GET, POST, PUT, DELETE). Explicando de um jeito prático, ele é uma evolução dos exemplos que acabamos de ver com GET ou POST. No REST, as requisições são feitas com GET, POST e até com outros métodos menos conhecidos do protocolo HTTP, como PUT e DELETE. A questão é mais sobre como isso é padronizado, e é isso que vamos estudar neste livro. Nota: Qual a diferença entre REST e RESTful? REST é um conjunto de técnicas de desenvolvimento de web services fortemente atreladas ao protocolo HTTP e a diversos padrões já existentes da web. Web services construídos com estas técnicas são chamados de web services RESTful.
Capítulo 1 ■ Introdução
27
1.7 Estrutura do livro Os primeiros capítulos do livro mostram como instalar o MySQL e preparar o banco de dados que vamos utilizar durante nossos estudos. Logo depois temos uma introdução ao desenvolvimento web para Java, para aprendermos os fundamentos necessários para prosseguir nos estudos. Inclusive, caso você se sinta familiar com estas tecnologias, poderá passar os olhos rapidamente nestes capítulos e prosseguir. No capítulo 5, sobre web service básico, eu explico como fazer estes web services simples em GET e POST, mas utilizando a linguagem Java. Os web services vão retornar dados em XML e JSON. Isso nos dará a base necessária para estudar o REST no capítulo 6. Como já explicado, o REST utiliza o protocolo HTTP para fazer as requisições por GET, POST etc., mas a grande sacada é a padronização de como estas chamadas são feitas, e as técnicas utilizadas para isso. Até a metade do livro, vamos focar o desenvolvimento dos web services, mas, a partir da segunda metade, vamos aprender a criar um servidor na nuvem do Google. Isso vai permitir colocar nossos web services na internet para qualquer sistema utilizar. Como prova de conceito final, inclusive teremos capítulos extras sobre AngularJS e Android.
1.8 Capítulos extras Neste livro seremos responsáveis por construir uma aplicação servidora completa, com diversos web services referentes a um cadastro de carros. Para demonstrar como utilizar os web services deste livro, teremos capítulos extras com exemplos de sistemas clientes. O capítulo 18 demonstra um pequeno sistema web com AngularJS (Figura 1.9), de modo que é possível listar os carros, inserir novos carros, editar, excluir, pesquisar etc. Não é objetivo do livro dar uma explicação detalhada sobre AngularJS, mas sim que este material lhe sirva de apoio e de complemento aos seus estudos. No capítulo 19, teremos outro exemplo de aplicação que utiliza estes web services. Desta vez, é um aplicativo para Android completo (Figura 1.10). O aplicativo é online e utiliza os web services criados neste livro, sendo possível inserir novos carros, tirar a foto do caro com a câmera e enviar os dados para o servidor.
28
Web services RESTful
Figura 1.9 – Sistema web com a lista de carros.
Figura 1.10 – Aplicativo para Android.
Capítulo 1 ■ Introdução
29
Novamente, não é objetivo deste livro explicar o desenvolvimento de aplicativos para Android, pois já fiz isso em outros livros. O objetivo aqui é turbinar os exemplos deste livro, de modo que este aplicativo seja visto como um “plus” para o livro, ou seja, um material complementar para seus estudos. Inclusive tenho plena confiança em que, se você leu meu livro sobre Android, você não terá problemas para entender como este aplicativo funciona, pois é praticamente o mesmo exemplo demonstrado passo a passo durante o livro Google Android. Vale lembrar que meu livro de Android tem mais de mil páginas, portanto não faz sentido repetir nenhuma explicação aqui.
1.9 Computação em nuvem Cuidar da infraestrutura de servidores é algo complexo e envolve gerenciar recursos de redes, armazenamento, backup, processamento, memória, energia etc., e para auxiliar a gerenciar essa infraestrutura, empresas e desenvolvedores optam por contratar planos de hospedagem com empresas especializadas que tenham grandes datacenters. No plano de hospedagem são definidos antecipadamente todos os recursos computacionais que serão contratados. Esta abordagem clássica é muito utilizada, mas está perdendo cada vez mais espaço para a computação em nuvem, que inverte os papéis e permite à empresa ou ao desenvolvedor estar totalmente no controle e gerenciar seu próprio datacenter de forma simples e ágil. Mas, afinal, o que é computação em nuvem? Segundo a definição do NIST (National Institute of Standards and Technology), computação em nuvem é um modelo que permite um acesso a um pool compartilhado de recursos computacionais configuráveis (redes, servidores, armazenamento, aplicações e serviços) que podem ser rapidamente fornecidos e disponibilizados com um mínimo esforço de gestão ou interação com o fornecedor do serviço. O exemplo mais clássico de computação em nuvem é armazenar arquivos na internet, mas, segundo essa definição do NIST, podemos entender que se trata de algo bem mais amplo, pois estamos falando de acessar qualquer recurso de TI sob demanda, como, por exemplo, criar vários servidores na nuvem e acessar serviços computacionais para auxiliar a desenvolver aplicações. Os provedores de serviços de nuvem, como Google, Amazon, Microsoft, DigitalOcean etc., oferecem páginas web que facilitam o gerenciamento de seus recursos da nuvem, e com este modelo é você que está no comando do seu datacenter. Caso você precise de mais espaço de armazenamento, você poderá configurar
30
Web services RESTful
mais espaço com poucos cliques em questão de minutos, sem a necessidade de abrir nenhum chamado no datacenter. Você também pode melhorar a capacidade computacional dos seus servidores ou até adicionar mais servidores facilmente. Isso pode ser feito por você manualmente, automaticamente ou até pela API, utilizando alguma linguagem de programação. A principal vantagem da nuvem é que não precisamos nos preocupar com recursos de TI, pois, para nossos olhos, eles são infinitos. Este modelo permite usufruir da grande infraestrutura disponibilizada na nuvem e focar apenas no desenvolvimento das aplicações. Outro conceito importante da nuvem é o pagamento conforme a demanda, ou seja, você paga conforme utiliza os serviços. Então, se você armazenar 500 GB de arquivos, você pagará somente por isso. E se você tiver três servidores na nuvem, você pagará somente enquanto eles estiverem ligados. O mesmo conceito vale para qualquer outro tipo de serviço existente na nuvem. Neste livro, vamos estudar a plataforma de computação em nuvem do Google, chamada Google Cloud Platform, ou seja, depois de aprender a construir os web services, vamos criar um servidor na nuvem do Google, o gigante da internet.
1.10 Links úteis Depois de ler este livro, você estará apto a criar web services RESTful utilizando a linguagem Java e instalá-los na nuvem do Google para desenvolver aplicações de alta disponibilidade e escalabilidade. No final de cada capítulo você encontrará links úteis para complementar seus estudos. Por ora, deixo para sua consulta o link do site do livro, caso queira obter mais informações. • Livro Web Services: http://livrowebservices.com.br/ Se tiver interesse em acompanhar mais de perto meu trabalho e os próximos lançamentos, seguem os links das redes sociais. • Google+: https://plus.google.com/+RicardoLecheta/posts • Facebook: https://www.facebook.com/ricardolecheta • Twitter: https://twitter.com/rlecheta • Novatec Editora: http://novatec.com.br/livros/