Webservices REST e PHP, Introdução

Introdução

Já à algum tempo o REST tornou-se a principal arquitetura para criação de webservices para aplicações web e mobile. Todas principais linguagens de programação incluem frameworks para criação de Webservices REST. É importante que todo desenvolvedor e arquiteto tenha um claro entendimento de como o ele funciona. O objetivo deste artigo é realizar um overview introdutório sobre a tecnologia por trás do REST e quais os caminhos para implementação do mesmo na linguagem PHP.

REST significa REpresentational State Transfer. REST não é um protocolo, mas sim uma série de princípios arquiteturais para você possa construir webservices que irão consumir recursos de um sistema. É comum encontrar uma range amplo de serviços REST desenvolvidos em diversas linguagens.

É muito comum também ouvirmos falar do termo ‘RESTful’. Uma API RESTful é uma API remota que segue o estilo arquitetural do REST.

REST vs SOAP

Caso esteja estudando sobre Webservices, muito provavelmente já ouviu falar sobre SOAP. Apesar do foco deste artigo é falarmos sobre Webservices REST, gostaria de destacar as principais diferenças entre esses duas principais abordagens quando falamos de Webservices, para que você possa perceber essas diferenças e poder encontrar a melhor opção para cada situação.

  1. SOAP é considerado um protocolo, enquanto REST é um estilo arquitetural.
  2. REST é muito mais simples que SOAP. Criar clients, desenvolver APIs e documentar é muito mais fácil e simples em REST.
  3. REST permite diferentes formatos para dados (JSON, XML, etc,), enquanto SOAP permite somente XML. JSON por exemplo, é enxuto e tem processamento rápido, além de ter suporte nativo em javascript.
  4. REST tem uma melhor performance e escalabilidade, além de poder ser cacheado. SOAP não pode ser cacheado
  5. Uma das vantagens do SOAP é o suporte à WS-Security que adiciona camadas de segurança extras além das suportadas através de HTTP, SSL, etc. Isso lhe dá algumas vantagens em determinadas finalidades no mundo “Enterprise”.
  6. SOAP suporta transações ACID (Atomicity, Consistency, Isolation, Durability) – mesmo conceito encontrado em transações de banco de dados. REST também suporta transações mas não abrangente como o SOAP.

O objetivo aqui foi apenas ilustrar alguma diferenças entre as duas principais abordagens para construção de webservices. Lembrando que REST é o mais utilizado e predominante para webservices ! APIs do Yahoo, Amazon, Goole, Ebay estão todos em REST.

SOAP se torna interessante em algumas situações mais específicas. Por exemplo, Webservices de aplicativos para bancos. Seria mais interessante SOAP devido à recursos mais avançados de segurança e de transações.

Métodos HTTP

Praticamente todos Webservices usando REST usam HTTP como camada de transporte por padrão, apesar de não haver nenhuma restrição no REST para que HTTP seja mandatório para a camada de transporte.

HTTP é a opção padrão devido a uma série de fatores favoráveis e pelo seu amplo alcance em servidores, bibliotecas, infraestrutura, etc. O casamento entre REST e HTTP funciona muito bem.

Uma das características de Webservices REST, quando usado com HTTP, é o uso explícito de seus métodos: GET, POST, PUT e DELETE.

Recomendação: POST ao criar um recurso, GET para consultar, PUT para atualizar e DELETE para remover. Veja a tabela abaixo onde mapeamos a operações CRUD com métodos HTTP:

TarefaComando HTTP
Criar (INSERT)POST
Ler (SELECT)GET
Atualizar (UPDATE)PUT
Excluir (DELETE)DELETE

Porém, nem sempre devemos levar em consideração essas regras ao pé da letra. Por exemplo, PUT e POST podem ser usados de formas diferentes de acordo com as circunstâncias. É possível utilizar ambos para criação de novos recursos. Usar PUT quando precisar atualizar um recurso por completo. Usar POST para atualizar parte de um objeto ou modificação em uma URL. Lembrando que você não precisa necessariamente adotar ambos em seu projeto, apesar das recomendações.

Caso queira se aprofundar mais no assunto entre PUT vs POST, sugiro a leitura:
http://stackoverflow.com/questions/630453/put-vs-post-in-rest
http://restcookbook.com/HTTP%20Methods/put-vs-post/

Ser Stateless

Ser Stateless significa que o webserver não mantém nenhum estado do client no lado do servidor. Isso significa que uma requisição REST, através de HTTP, é uma requisição completamente isolada. A requisição deve conter todas as informações suficientes para o servidor processa-la por completo.

Normalmente quando trabalhos com sessões no PHP, em uma aplicação web tradicional, os dados da sessão são mantidas no servidor, ou seja, é um ambiente considerado Stateful e não Stateless.

Uma API RESTful deve funcionar de forma Stateless. Principais vantagens:

  • Webservices podem tratar cada método de requisição de forma independente
  • Devido a não precisar manter interações prévias do usuário, facilita o design da aplicação.
  • O HTTP por si só é considerado um protocolo stateless. Isso contribui com as APIs em REST que usam o HTTP como camada de transporte.
  • Ser stateless, melhora a performance do webservice. Devido a falta da necessidade de sincronização de estados do cliente entre servidores, facilita a escalabilidade da aplicação, como, subir novos servidores, utilização de clusters, load balancing, failover, gateways, etc.

Transferindo Dados

É muito comum o uso do formato JSON em APIs RESTful para a transferência de dados entre o Server e o Client.

JSON, ou JavaScript Object Notation, é derivado do Javascript e usado para representar estrutura de dados de uma forma simples. Apesar da relação com o Javascript, é independente de linguagem, contendo parsers em praticamente todas linguagens de programação.

JSON se tornou uma alternativa atraente ao XML para representação de dados que são trafegado através de rede, em comunicação com Webservices. Muito provavelmente seu Webservice já utiliza ou utilizará JSON.

Porém nada impede que você utilize mais de um formato para transferir dados no seu webservice.
Você pode usar JSON, XML entre outros, ao mesmo tempo. Isso fará com que seu serviço pode ser usado por uma variedade de clients escritos em diferentes linguagens, rodando em diferentes plataformas ou devices.

Você pode deixar o client decidir qual o tipo de conteúdo deseja receber através do HTTP Header Accept. Exemplo:

GET /page/restful-framework HTTP/1.1
Host: xpto.org
Accept: application/json

Altere o Accept para solicitar um formato de retorno diferente: (xml)

Accept: application/xml

Lembrando que seu Webservice deve estar preparado para apresentar diferentes tipos de formatos!

Autenticação

Como já vimos anteriormente, uma API RESTful deve ser Stateless, ou seja o servidor não deve manter nenhum estado do client através de uma session por exemplo. A requisição deve ser processada de uma única vez, apenas com as informações contidas na própria requisição.

Existem várias formas de manter a segurança de sua API. Vou mencionar aqui algumas das mais conhecidas e usadas. Lembre-se que o objetivo não é eleger a melhor, e sim apresentar as possibilidades. A escolha depende das características particulares de cada projeto.

  • Basic HTTP Authentication: Com certeza é a forma mais rápida e fácil de adicionar alguma segurança em sua API. Qualquer linguagem para web tem suporte para esse tipo de autenticação. Não há necessidade de nenhuma biblioteca externa. Porém é um mecanismo muito “básico”. O usuário e senha são encodados em Base64 para serem transferidos. Nunca utilize esse tipo de autenticação sem SSL (https), devido a facilidade de decodificação do Base64.
  • OAuth 2: OAuth é outra grande opção para garantir segurança de sua API REST. OAuth é um framework open source para autenticação e autorização de forma segura. Contendo métodos para web, mobile e aplicações desktop. Você pode encontrar mais informações sobre oauth em http://oauth.net/2/. Inclusive implementações em PHP.
  • Token Based Authentication: Você pode implementar um mecanismo de token mais simples que o OAuth para garantir a autenticação de sua API RESTful. Basicamente você faz uma requisição em um determinado endpoint informando usuário e senha da aplicação. Com a autenticação válida, será retornado um token para ser usado como identificação do usuário nas próximas requisições em páginas protegidas. Lembrando que o token tem um tempo de expiração e que devemos continuar mantendo o conceito de stateless.
    Veja aqui um exemplo bem básico de implementação.

REST e PHP

RESTful Webservices

Como vimos até agora, APIs RESTful usadas sob HTTP utilizam métodos como GET, POST, DELETE, PUT, etc. O PHP por padrão já esta pronto para tratar esses tipos de requisições. Portanto, você consegue escrever Webservices REST sem uso adicional de nenhum framework. Lógico que o uso de frameworks irá facilitar bastante o seu trabalho. No caso, o uso de micro-frameworks é uma ótima opção, tanto para sistemas pequenos quanto grandes. Indicações:

Vantagens:

  • Micro-frameworks são rápidos, otimizados e com bom suporte para modularização.
  • Todos possuem boa documentação e suporte da comunidade além de bons tutoriais.
  • Facilidade em configuração de rotas baseadas em URL

Apigility

Apigility é um projeto open source da Zend com o objetivo de criar APIs (REST e RPC) de qualidade, de forma rápida e fácil, tendo em mente padrões e boas práticas encontradas na industria atual.

Apigility fornece uma interface web de administração que facilita os desenvolvedores na criação e configuração de APIs. Apigility consiste em uma coleção de módulos do ZF2. É standalone, ou seja, o projeto da sua API não precisa estar usando ZF2 para funcionar, apesar que se estiver, você terá algumas vantagens em cima disso! E se estiver usando Zend Studio, também terá mais algumas vantagens.

Algumas características interessantes:

  • Autenticação HTTP Basic, HTTP Digest e OAuth2 são suportadas na solução e podem ser facilmente configuradas.
  • Representações em JSON, XML ou HAL (Hypermedia Application Language) também podem ser facilmente configuradas e implementadas.
  • Diferentes tipos de versionamento da API, via URL, Media Type ou Code Namespace.
  • Paginação embutida e invocada automaticamente.

Mais dicas sobre o Apigility no site oficial.

REST Api Clients

Você pode construir uma API para consumir webservices REST simplesmente utilizando a extensão CURL para PHP.

Ou, se preferir, recomendo utilizar uma boa biblioteca de http client para PHP. Você irá economizar código além de deixar seu fonte bem mais legível. Nesse caso eu recomendo o Guzzle Http Client, http://guzzlephp.org/. Existem outras bibliotecas http client boas para php, mas na minha opinião a Guzzle é uma das melhores.

Conclusão

Procurei abordar neste artigo algumas características importantes do REST e também sugerir alguns caminhos e recursos para implementação de Webservices na linguagem PHP. Existe muito mais assunto para falarmos de REST e PHP. Espero abordar em breve mais desses assuntos. Torço para que lhe seja útil. Até a próxima.

Referências

https://www.ibm.com/developerworks/library/ws-restful/
http://restcookbook.com/
http://spf13.com/post/soap-vs-rest
http://www.drdobbs.com/web-development/restful-web-services-a-tutorial/240169069
http://www.gajotres.net/best-available-php-restful-micro-frameworks/3/#ch5

Comments

  1. Reply

    • By Douglas V. Pasqua

      Reply

  2. By Douglas

    Reply

    • By Douglas V. Pasqua

      Reply

  3. Reply

    • By Douglas V. Pasqua

      Reply

  4. By Djalma Manfrin

    Reply

    • By Douglas V. Pasqua

      Reply

  5. Reply

  6. By Geovane Krüger

    Reply

    • By Douglas V. Pasqua

      Reply

  7. Reply

    • By Douglas V. Pasqua

      Reply

Deixe um comentário

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: