O que é REST?

Segundo a Wikipedia “A Transferência de Estado Representacional (Representational State Transfer) ou somente (REST) é uma técnica de engenharia de software para sistemas hipermídia distribuídos como a World Wide Web. O termo se originou no ano de 2000, em uma tese de doutorado (PHD) sobre a web escrita por Roy Fielding, um dos principais autores as especificação do protocolo HTTP que é utilizado por sites da internet ”.

Com essa técnica é possível criar serviços na WEB sem a necessidade de RPC ou SOAP. A definição dos serviços são através de recursos. Esse recursos são identificados por suas URLs, cada URL é um recurso único e de deve estar definido em local único, assim se você tiver, por exemplo, uma aplicação MVC, que tem 2 controles, neste exemplo, Contas e Feeds, você deverá eleger quais recursos estarão disponíveis aos seus clientes.

Vamos imaginar que você quer disponibilizar o recurso http://nossorest.example.com/api/account/ para informações e edição de uma conta no sistema. Neste casso você quer por exemplo que o controle AccountController seja usando com a action infoAction e editAction. Para isso você deve mapear nas suas rotas que quando a requisição para esse URL seja encaminhada para o controle e ação correta. Nesse artigo não vou considerar o uso de MVC ou outra metodologia. Apenas vou ter 2 arquivos que vão implementar os recursos.

O REST trabalha com os códigos do protocolo HTTP e seus verbos, a seguir você vera os principais códigos de retorno e seus usos e os verbos utilizados. Uma coisa que é importante ressaltar é que o REST é principalmente semântico, assim dispensa muitos arquivos de documentação.

Principais códigos de retorno

O protocolo HTTP trabalha com classes de retorno que são 5, o numero inicial do código de retorno indica a classe de retorno, por exemplo o retorno 200 é da classe 2 que é sucesso.

Classes

• 1 – Continue, usando para continuar a mesma ação com varias requirições.
• 2 – Sucesso.
• 3 – Redirecionamento
• 4 – Erro do cliente
• 5 – Erro do servidor

Códigos mais usados pelas aplicações REST

• 200 – Sucesso, mais trivial resultado, usado por padrão
• 201 – Criado.
• 401 – Não autorizado, possivelmente porque não houve uma autenticação no servidor.
• 403 – Acesso negado
• 404 – Recurso não encontrado.
• 412 – Precondição falhou, quando um dado não foi informado ou informado de forma equivocada.
• 500 – Erro interno no servidor, geralmente usado quando uma exceção sem tratamento é lançada.
• 501 – Recurso não implementado, geralmente quando esta na especificação e não foi ainda implementado.

Os verbos

• GET – usado para obter um recurso ou uma lista deles.
• POST – usado para incluir um recurso
• PUT – usado para editar um recurso
• DELETE – usado para deletar um recurso

O corpo da resposta pode ser em qualquer estrutura que você quiser. Usaremos a estrutura JSON, mas poderia ser XML ou outra estrutura, inclusive texto puro.

Os nossos arquivos conterão a seguinte estrutura:

/api/acount/index.php


<?
/* Nossa classe de conta. */
require_once 'Classe/Account.php';

$accounts = new Account();

/* verifica se p metodo é o GET */
if ($_SERVER['REQUEST_METHOD'] == ‘GET’)
{
/*Caso seja, busca os dados do conta solicitada, caso não, toda a lista */
if ($_GET['id'])
{
$account = $account->find($$_GET['id'])->current();

/* verifica se o recursos existe */
if ($account)
{
/*caso exista imprime uma estrutura json com a estrutura da conta */
echo json_encode($account->toArray());
}
else
{
/* retorna o código de retorno 404, recursos não encontrado. */
http_send_status(’404′);
}
}
}
elseif ($_SERVER['REQUEST_METHOD'] == ‘PUT’)
{
/* o método PUT é utilizado para editar um recurso */
if ($_GET['id'])
{
$account = $accounts->find($_GET['id'])->current();
if ($account)
{
$account->name = $_GET['name'];
$account->email = $_GET['email'];

try
{
/* não precisamos mudar o código do retorno, pois será 200 */
$account->save();
}
catch (Exception $e)
{
/* erro interno no servidor; */
http_send_status(’500′);
}

}
else
{
/* retorna o código de retorno 404, recursos não encontrado. */
http_send_status(’404′);
}
}
else
{
/* se o recurso não foi indicado envia um erro de falha de precondição */
http_send_status(’412′);
}
}
else
{
/* acesso negado para os métodos POST e DELETE */
http_send_status(’403′);
}
?>
O segundo recurso (Feed)que esta na URL http://nossorest.example.com/api/feed/ será usado para incluir, listar e deletar feeds de uma determinada conta.

/api/feed/inde.php

<?
/*Nossa classe de conta.*/
require_once 'Classe/Account.php';

$accounts = new Account();

/*verifica se o metodo é o GET*/
if ($_SERVER['REQUEST_METHOD'] == ‘GET’)
{
/*Caso seja, busca os dados da conta solicitada*/
if ($_GET['id'])
{
$account = $account->find($$_GET['id'])->current();

/*verifica se o recursos existe*/
if ($account)
{
/*caso exista imprime uma estrutura json com a estrutura da conta*/
echo json_encode($account->getFeeds());
}
else
{
/*retorna o código de retorno 404, recursos não encontrado.*/
http_send_status(’404′);
}
}
else
{
/*se o recurso não foi indicado envia um erro de falha de precondição*/
http_send_status(’412′);
}
}
elseif ($_SERVER['REQUEST_METHOD'] == ‘POST’)
{
/*Caso seja, busca os dados da conta*/
if ($_GET['id'] and $_GET['feed'])
{
$account = $account->find($$_GET['id'])->current();

/*verifica se o recursos existe*/
if ($account)
{
/*caso exista inclui a feed na lista da conta*/
$account->addFeed($_GET['feed']);
}
else
{
/*retorna o código de retorno 404, recursos não encontrado.*/
http_send_status(’404′);
}
}
else
{
/*se o recurso não foi indicado envia um erro de falha de precondição*/
http_send_status(’412′);
}
}
elseif ($_SERVER['REQUEST_METHOD'] == ‘DELETE’)
{
/*o método PUT é utilizado para editar um recurso*/
if ($_GET['id'] and $_GET['id_feed'])
{
$account = $accounts->find($_GET['id'])->current();
if ($account)
{
$account->delFeed($_GET['id_feed']);
}
else
{
/*retorna o código de retorno 404, recursos não encontrado.*/
http_send_status(’404′);
}
}
else
{
/*se o recurso não foi indicado envia um erro de falha de precondição*/
http_send_status(’412′);
}
}
else
{
/*acesso negado para o método PUT*/
http_send_status(’403′);
}
?>
Com esses exemplos práticos você já pode começar a imaginar como serão seus serviços e
começar a mapeá-los. Durante essa semana estarei publicando mais artigos que elucidaram ainda mais como criar aplicações em PHP com REST e MVC com o Zend Framework.

Abraços,
Fernando Chucre

durante o horário de trabalho tenho a sorte de debater com pessoas competentes e interessadas, sobre os assuntos mais quentes de tecnologia, um tipo de “otium”(ócio em latim) criativo coletivo. È sempre um prazer discutir idéias com amigos-colegas. Em um desses papos eruditos sobre tecnologia, estava conversando com meu amigo Christiano Milfont
sobre umas das tecnologias mais exóticas da web 2.0 : a tecnologia REST. Na verdade REST é um conceito, uma arquitetura web, é uma diferente maneira de implementar serviços web. Se trata de implementar serviços web orientados a recursos. Com REST Web services são reimplementados através de URI,HTTP,XML. REST é diferente de SOAP ou RPC. REST não é um padrão W3C, é uma arquitetura web, assim como Ajax.

Porque URI, HTTP e XML? As tres são interfaces extensiveis . Podem ser formadas um numero infinito de URIs e por isso podem ser usadas para ser identificadoras de recursos. Indicam o endereço e o nome dos recursos publicados. HTTP é um protocolo que suporta métodos, cabeçalhos e URIs nativamente. XML …acho que não precisa nem de explicações. As tres sustentam a web. Até aqui nada de novo.

A novidade vem com como que vou arranjar essas três tecnologias para consumir recursos.

Primeiro, os recursos são o que? Podem ser qualquer formato do XML ao JSON, do TXT ao Html,ou um JPEG,GIF… Não importa qual o formato o importante é que pode-se interagir diretamente com esses recursos via HTTP.

Por exemplo:

quero acessar claudio/servico/relatorio, acessando retorna um arquivo(recurso) xml.

“claudio/servico” é o endereco, “relatorio” é o nome do recurso que retorna um xml, juntos são um ID único do recurso na web.

O interessante é que os componentes da web em que são hospedados esses recursos conversam entre si com um protocolo comum, o HTTP. O HTTP possui metodos, URI, status, cabeçalhos e tipos MIME.

Alguns desses métodos são POST, GET, PUT, DELETE. Cada um desse métodos tem finalidades precisas POST=Create, GET=Read, PUT=Update DELETE=Delete …lembra alguma coisa? Um CRUD? Isso mesmo. Podemos agir em cima dos recursos via métodos HTTP assim como se faz com um crud.

Logo em seguida publicarei um exemplo para entender melhor essa tecnologia

Abçs

Claudio Ulisse

Design patter é, na computação, a abstração de um problema prático no desenvolvimento de software, ou melhor, é um modelo reusável de resolução de problemas. Um design pattern explica os passos fundamentais para resolver um problema em geral. Ele não ajuda a implementar o código em si, mas ajuda na lógica da resolução do problema. Os design pattern conhecidos são orientados a objetos mostrando as interações entre objetos e as estratégias para lidar com eles, dependendo do problema. Mesmo assim não definem a arquitetura da aplicação, com os componentes, módulos e sub-módulos. Esses são outros tipos de patterns, chamados arquiteturais, que definem o esqueleto do software. O foco dos design patterns são objetos e as interações entre eles.

O foco do SOA são os serviços. Muito já se falou a respeito de SOA e com certeza é o presente e o futuro do desenvolvimento corporativo. Os Arquitetos SOA se deparam com problemas similares dos analistas de sistemas de informação, afinal os dois tem que arranjar de maneira eficiente componentes que no conjunto tem que funcionar. O analista SI pensa “com qual padrão vou arranjar as minhas classes e objetos? qual vai ser a cara mo deu sistema?”, enquanto o arquiteto SOA pensa “como que vou arranjar os meus serviços? qual o design para o meu problema e que me garanta baixo acoplamento?”. Nesse ponto SOA pattern são um assunto novo. Inclusive livros e documentação sobre isso está saindo agora das editoras. Atualmente, o que eu descobri fuçando na web é que existem 60 SOA pattern, que na verdade são propostas de patterns. Existem livros com várias propostas, o que eu não vi até agora é uma sistematização dos padrões( ops é pattern!) SOA.

Convido vocês a comentar sobre esse assunto e espero muitas sugestões a respeito, porque a minha intenção é postar mais sobre isso.

Claudio Ulisse