Daniel Schmitz
Novatec
Copyright © 2013 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 Revisão gramatical: Naomi Yokoyama Editoração eletrônica: Carolina Kuwabata Capa: Carolina Kuwabata ISBN: 978-85-7522-360-4 Histórico de impressões: Junho/2013
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 Fax: +55 11 2950-8869 E-mail: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec VC20130617
capítulo 1
Considerações iniciais
1.1 Introdução A linguagem PHP vem ao longo dos tempos conseguindo acompanhar as mais recentes tecnologias empregadas pelos desenvolvedores de sistema, desde a época em que o PHP não era considerado uma linguagem orientada a objetos até os dias de hoje, com a implementação de padrões de sistemas e do uso constante de uma arquitetura orientada a objetos. Quando um novo padrão de projeto torna-se evidente como uma boa prática de programação no desenvolvimento de sistemas web, o PHP o acompanha por meio do surgimento de novos frameworks e de modificações importantes em sua linguagem. Em resumo, o PHP vem ao longo de uma década conseguindo se destacar como a linguagem preferida entre os desenvolvedores, tornando o seu domínio muito importante para os desenvolvedores que desejam desenvolver sistemas para a web. Como a evolução do desenvolvimento de sistemas está acelerando de uma forma muito rápida, nós, desenvolvedores, temos um problema crescente, que é o acompanhamento dessas novas tecnologias. Quando terminamos um sistema utilizando a tecnologia “X”, possivelmente já existirá a solução “Y”, que será melhor, e possivelmente teríamos que, de alguma forma, atualizar o nosso sistema. Dessa forma, como podemos nos proteger dessa constante evolução e desenvolver sistemas que possam ser utilizados durante um ciclo de vida maior e protegido de novas tecnologias que surgem a todo instante? 11
12
Criando Sistemas RESTful com PHP e jQuery
Este livro aborda uma forma de minimizar esse problema, garantindo uma independência entre as camadas servidor e cliente que compõem o sistema web, fazendo com que as tecnologias utilizadas possam ser substituídas, minimizando danos que levam a uma refatoração mais dolorosa.
1.2 Como o RESTful pode nos ajudar Para que possamos entender como o RESTful pode nos ajudar, temos que inicialmente aprender um pouco sobre o que é REST (Representational State Transfer, ou seja, Transferência de Estado Representativo), que é uma técnica de engenharia de software para sistemas hipermídia como a web. O termo REST é muito amplo e diversas representações podem ser ligadas a ele. Dessa forma, surgiu um conceito mais específico ligado às requisições web, o qual chamamos de RESTful, que obedece às regras do REST e implementa uma interface simples de acesso e resposta a uma requisição web, que pode ser realizada por meio de XML e/ou JSON. Como o JSON é uma forma mais leve de representar um estado, é mais comum utilizar RESTful com JSON em vez do XML. Você pode entender o RESTful como uma forma universal de “trocar” dados entre o cliente e o servidor, algo muito parecido com web services, que já foram amplamente abordados nas tecnologias web. Utilizar RESTful significa que o acesso ao servidor é usado para obter dados de forma stateless, ou seja, o sistema cliente não conhece o estado do servidor e vice-versa. O RESTful, assim como web services, obedece a algumas regras para que possa ser implementado de forma correta.
1.3 Como o RESTful funciona Vamos abordar o RESTful por meio do seu conceito mais básico, dividindo-o em entrada e saída. Todo acesso a um servidor web resume-se a uma requisição (entrada) e a uma saída (resposta). No RESTful, a requisição e a resposta podem ser configuradas da seguinte forma:
13
Capítulo 1 ■ Considerações iniciais
A entrada é definida pela URL de acesso ao servidor, e essa URL obedece aos métodos HTTP: GET, POST, PUT, DELETE. Os métodos GET e POST já são conhecidos na tag <form> dos formulários HTML, já PUT e DELETE podem ser novos para você. Basicamente, temos a seguinte convenção: • GET é usado para listar dados, listar um registro ou um cálculo. • POST é usado para adicionar dados. • PUT é usado para editar dados. • DELETE é usado para deletar dados. Na prática, temos as convenções mostradas na tabela 1.1: Tabela 1.1 – Convenções do RESTful Convenção GET /tarefas GET /tarefas/findAll/Manutenção GET /tarefas/1 POST /tarefas/ PUT /tarefas/1 DELETE /tarefas/1 GET /tarefas/concluidas
Descrição Obter todas as tarefas – método getAll da classe tarefas. Obter todas as tarefas por meio de uma busca por “manutenção” – método findAll. Obter a tarefa cujo id é 1 – método getById. Adicionar uma tarefa – método addTarefas. Editar uma tarefa cujo id é 1 – método editTarefas. Deletar uma tarefa cujo id é 1 – método deleteTarefas. Chamar o método concluidas da classe tarefas.
As regras criadas nessa tabela não são específicas do RESTful, são específicas do seu projeto. O padrão RESTful está presente apenas na especificação GET, POST, PUT e DELETE. Quando o cliente faz a requisição ao serviço RESTful, ele aguarda uma resposta que, na maioria das vezes, é uma resposta no formato JSON. Poderia ser um texto puro ou então XML, mas vamos adotar sempre o formato JSON. O formato JSON é composto por um formato em modo texto que delimita objetos com chaves e arrays com colchetes. Por exemplo, o objeto Pessoa poderia ser representado pela seguinte forma: {'nome': 'Daniel', 'email': 'Daniel@gmail.com'}
14
Criando Sistemas RESTful com PHP e jQuery
Já um array de objetos pode ser representado da seguinte forma: "employees": [
{ "firstName":"John" , "lastName":"Doe" },
{ "firstName":"Anna" , "lastName":"Smith" },
{ "firstName":"Peter" , "lastName":"Jones" }
]
1.4 Vantagens do RESTful Com esse padrão, tanto o servidor quanto o cliente ficam independentes entre si, já que o cliente se comunica com o servidor por meio de uma requisição HTTP e o servidor responde ao cliente por meio de JSON. Nesse contexto, não importa se o servidor é Java ou PHP e não importa se o cliente é Flex ou HTML, contanto que o padrão de comunicação seja mantido. E qual a vantagem disso? Você poderá trocar a tecnologia, seja servidor ou cliente, sem necessitar alterar tudo. Por exemplo, suponha que você tenha um sistema feito com Flex e PHP, e que você não tenha usado RESTful. Então o servidor poderia se comunicar com o Flex por meio de um protocolo próprio, como o AMF, que é um protocolo muito rápido para comunicação entre o Flex e o servidor. Caso houvesse a necessidade de implementar o mesmo sistema, só que agora em HTML 5, possivelmente você teria de reescrever os seus métodos PHP de forma que o AMF não pudesse mais ser usado. Se o RESTful estivesse implementado, você não poderia usar AMF, mas teria um servidor RESTful capaz de se comunicar com o Flex por meio de requisições HTTP e respostas em JSON. Nesse contexto, ao alterar a tecnologia do cliente para HTML, bastaria programar de forma que o seu cliente pudesse entender o RESTful, e os códigos que estão no servidor, em teoria, não sofreriam nenhuma alteração.