Vous êtes sur la page 1sur 6

Daniel Schmitz

Novatec

Copyright 2013 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. proibida a reproduo desta obra, mesmo parcial, por qualquer processo, sem prvia autorizao, por escrito, do autor e da Editora. Editor: Rubens Prates Reviso gramatical: Naomi Yokoyama Editorao eletrnica: Carolina Kuwabata Capa: Carolina Kuwabata ISBN: 978-85-7522-360-4 Histrico de impresses: Junho/2013 Primeira edio

Novatec Editora Ltda. Rua Lus Antnio dos Santos 110 02460-000 So 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

CAPTULO 1

Consideraes iniciais

1.1 Introduo
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 no era considerado uma linguagem orientada a objetos at os dias de hoje, com a implementao de padres de sistemas e do uso constante de uma arquitetura orientada a objetos. Quando um novo padro de projeto torna-se evidente como uma boa prtica de programao no desenvolvimento de sistemas web, o PHP o acompanha por meio do surgimento de novos frameworks e de modicaes importantes em sua linguagem. Em resumo, o PHP vem ao longo de uma dcada conseguindo se destacar como a linguagem preferida entre os desenvolvedores, tornando o seu domnio muito importante para os desenvolvedores que desejam desenvolver sistemas para a web. Como a evoluo do desenvolvimento de sistemas est acelerando de uma forma muito rpida, ns, desenvolvedores, temos um problema crescente, que o acompanhamento dessas novas tecnologias. Quando terminamos um sistema utilizando a tecnologia X , possivelmente j existir a soluo Y , que ser melhor, e possivelmente teramos que, de alguma forma, atualizar o nosso sistema. Dessa forma, como podemos nos proteger dessa constante evoluo 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 independncia entre as camadas servidor e cliente que compem o sistema web, fazendo com que as tecnologias utilizadas possam ser substitudas, minimizando danos que levam a uma refatorao 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, Transferncia de Estado Representativo), que uma tcnica de engenharia de software para sistemas hipermdia como a web. O termo REST muito amplo e diversas representaes podem ser ligadas a ele. Dessa forma, surgiu um conceito mais especco ligado s requisies web, o qual chamamos de RESTful, que obedece s regras do REST e implementa uma interface simples de acesso e resposta a uma requisio 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 signica que o acesso ao servidor usado para obter dados de forma stateless, ou seja, o sistema cliente no 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 bsico, dividindo-o em entrada e sada. Todo acesso a um servidor web resume-se a uma requisio (entrada) e a uma sada (resposta). No RESTful, a requisio e a resposta podem ser conguradas da seguinte forma:

Captulo 1 Consideraes iniciais

13

A entrada denida pela URL de acesso ao servidor, e essa URL obedece aos mtodos HTTP: GET, POST, PUT, DELETE. Os mtodos GET e POST j so conhecidos na tag <form> dos formulrios HTML, j PUT e DELETE podem ser novos para voc. Basicamente, temos a seguinte conveno: GET usado para listar dados, listar um registro ou um clculo. POST usado para adicionar dados. PUT usado para editar dados. DELETE usado para deletar dados. Na prtica, temos as convenes mostradas na tabela 1.1:
Tabela 1.1 Convenes do RESTful
Conveno
GET /tarefas GET /tarefas/findAll/Manuteno GET /tarefas/1 POST /tarefas/ PUT /tarefas/1 DELETE /tarefas/1 GET /tarefas/concluidas

Descrio Obter todas as tarefas mtodo getAll da classe tarefas. Obter todas as tarefas por meio de uma busca por manuteno mtodo findAll. Obter a tarefa cujo id 1 mtodo getById. Adicionar uma tarefa mtodo addTarefas. Editar uma tarefa cujo id 1 mtodo editTarefas. Deletar uma tarefa cujo id 1 mtodo deleteTarefas. Chamar o mtodo concluidas da classe tarefas.

As regras criadas nessa tabela no so especcas do RESTful, so especcas do seu projeto. O padro RESTful est presente apenas na especicao GET, POST, PUT e DELETE. Quando o cliente faz a requisio ao servio RESTful, ele aguarda uma resposta que, na maioria das vezes, uma resposta no formato JSON. Poderia ser um texto puro ou ento 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 padro, tanto o servidor quanto o cliente cam independentes entre si, j que o cliente se comunica com o servidor por meio de uma requisio HTTP e o servidor responde ao cliente por meio de JSON. Nesse contexto, no importa se o servidor Java ou PHP e no importa se o cliente Flex ou HTML, contanto que o padro de comunicao 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 no tenha usado RESTful. Ento o servidor poderia se comunicar com o Flex por meio de um protocolo prprio, como o AMF, que um protocolo muito rpido para comunicao 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 mtodos PHP de forma que o AMF no pudesse mais ser usado. Se o RESTful estivesse implementado, voc no poderia usar AMF, mas teria um servidor RESTful capaz de se comunicar com o Flex por meio de requisies 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 cdigos que esto no servidor, em teoria, no sofreriam nenhuma alterao.

Vous aimerez peut-être aussi