Server-side/ Web 2.0

REST é a melhor escolha para seus próximos projetos de mobile/desktop/api

rest_sample

É difícil de acreditar que a transferência simples de objetos entre chamadas ficou bem popular nos dias de hoje. Lá em meados de 2007 quando eu estava tão focado em RTMP, eu mal pude enxergar que isso poderia se tornar a soma de todas as soluções do lado do servidor.

À exemplo disso, tiramos o fato que transferência do objeto está associado a cabeçalho da mensagem, corpo da mensagem, o paradigma do REST é desacoplar essas dependências e atingir o máximo de clientes possíveis, já que se trata de uma chamada simples com um retorno simples.

Por exemplo, qual a relação do REST com o SOAP, bastante utilizado na plataforma ASP.Net, como mencionei acima, REST tem um cabeçalho simples de mensagem específica, sendo apenas uma requisição HTTP que você faz e que o cabeçalho não é nada mais que o código processado da requisição para o servidor, avisando que a requisição chegou ou falhou, etc.

Já no padrão SOAP, defini-se o cabeçalho com padrões semânticos e sintaxes XML, como é o caso das especificações 1.0, 1.1 e a tangível 1.2 que em alguns casos clientes que requisitam esse padrão não tem suporte.

Como todos estão acostumados à verem apenas os pros da coisa, eu vou pelo lado contrário definindo pelas falhas em cada lado da moeda. Os pros, vocês dão uma Googlada para achar.

As falhas de comparação do SOAP é basicamente:

  • Tradução do serviço em um formato de mensagem específica em XML
  • Cliente precisa ter suporte as especificas DTD.
  • Padrão XML definido por namespace
  • Desenvolvedor acaba tendo que remover os namespaces quando vai fazer o parse ou envio.
  • Tipação das entidades é feita pelos namespaces.
  • Todo erro é do tipo 500 ( dificil de advinhar sem fazer uma interface própria)

Já no lado REST

  • Não possui especificação, A pode ser A desde que seja definido de primeira instancia, ou acabará como Z.
  • Segurança fraca, já que não requer uma tipação na requisição. Só que tudo depende de quem implementa, oAuth por exemplo é um excelente meio de segurança aplicada.
  • Tipação de objetos é inexistente
  • Liberdade de output em JSON,text, XML ou seu próprio tipo.

Esses tipos de comparação entre SOAP e REST é o mesmo que comparar carro e avião ou maçã e banana, dificil de imaginar que ambos competem entre sí, mas ambos possuem ambas particularidades que atendem a específicos requisitos, que se julgam necessário pela mão do desenvolvedor.

Porém, você pode discordar dessas comparações, e eu posso até concordar em seus argumentos, já que o que define um serviço REST é se ele possue cache, se possui autenticação se possui uma URI simplificada e o mais importante, qualquer cliente pode consumí-lo.

Salve guardo essas diferenças simples, porém importantíssimas para a definição do serviço, REST caiu no gosto popular do desenvolvedor moderno, já que o serviço é apenas o produto do meio para o produto final.

Quando gigantes do software como Google, Yahoo, Amazon, Facebook, Microsoft, adotam esse padrão de consumo de informações, milhões e milhões de start-ups pelo mundo também copiam a idéia e implementam, afinal produtividade e RAD nunca saiu de moda nesses últimos 10 anos.

 

Enterprise e APIs

É fato comprovado que Enterprise é mais lenta que o ritmo da internet, só que o provérbio não deixa por ressaltar “Antes tarde do que nunca“. Mais de 8 mil APIs tem sido criada para o mundo start-up, ao invés de grandes empresas darem apenas o SDK para outros desenvolvedores consumir seus serviços ou sua plataforma, eles também tem visto que a API é fundamental para a ploriferação de seus produtos.

API, não significa apenas REST API, existem vários tipos de API, tanto incorporadas dentro do próprio SDK como é o caso das DLLs, COMs, só que hoje em um ambiente mais aberto, com várias opções de clientes, o mais sensato é construir serviços e disponibilizados da maneira mais abrangente possível.
Plataformas que criam serviços REST

Tomando como base que tecnologia é apenas o produto do meio, hoje todas as linguagens de programação que tenham implementado o protocolo HTTP 1.1, podem criar serviços REST na internet, desde o C até o Javascript(nodejs), podem criar serviços REST para serem consumidos por outras linguagens clientes.

A internet em sí é um estado de transferência representacional ( REST na sigla em inglês), que transfere recursos por URI simples, quando você requisitou o link desse site, você fez uma chamada REST por meio de uma URI simples, acaba que você está usando um REST por trás dessa requisição, é muito mais simples do que você imagina.

E qual o objetivo do REST?

Tornar as coisas simples, cache de objetos se necessário, desacopláveis, simplicidade de requisição, definir que um erro 404 é um erro 404 ou que um erro 403 seja um erro 403 e o mais importante, multi pluralidade dos recursos que estão sendo manipulados através de comandos básicos a serem executados pela requisição.

Se você leu até aqui, parabéns, viu que as idéias jogadas no inicio do post, tendem a ser mais relevantes para você nesse ponto do artigo, já que você tem a certa noção que uma API em REST é certeza que será utilizável por diferentes plataformas da maneira mais internetizada possível.

4 Métodos mágicos

GET/POST você já fez alguma vez na sua vida de desenvolvedor web, até mesmo um webdesigner já deve ter feito um formulário de contato. REST trabalha com mais dois tipos de requisições além desses, por que afinal ele transforma recursos (objetos) em URI simples e uma maneira frágil e certa, simplificar através de métodos as requisições economiza na hora de criar rotas para as URL.

  • GET – Ler/Retorna uma lista de recursos(objetos) para o lado cliente
  • POST – Cria um novo recurso(objeto) na lista já existente
  • PUT – Atualiza/Sobrescreve um objeto da coleção, caso não exista o objeto, ele assume o papel do POST criando-o.
  • DELETE – Remove/Apaga o objeto da coleção que você possui.

Qualquer cliente pode conectar

Se você tem um serviço que qualquer linguagem de cliente possa conectar, as chances são de que seu serviço seja consumido por 99.9% dos desenvolvedores de sua plataforma, como mencionei acima, Get/Post é por padrão uma requisição simples que qualquer navegador ou linguagem que implemente HTTP pode fazer.
O recurso de saída

Geralmente quando se pensa em REST, grande parte pensa que só retorna formato JSON, de fato, mais de 90% dos serviços REST implementam esse retorno, só que não é toda regra que não tenha uma excessão, REST pode retornar o formato que você precisar, .dat, .xml, .txt, .html, .script, o retorno é definível na definição do serviço.

Em resumo só o fato de você retornar em TEXTO simples, ou um texto formatado como JSON, você abre as portas para a universabilidade e interoperabilidade de sua API.
Segurança sob acima de qualquer suspeita

A camada de segurança de um REST está sob o que você quer proteger, o caso mais comum é login e senha, onde o nível de segurança seria apenas de autorização, se você implementa um serviço, o mínimo que você tem que fazer é isso, e o caso ideal é implementar no servidor uma autenticação HTTP ou oAuth que é o mais comum em casos de API REST.

Ser ou não ser oAuth é uma questão adversa as usabilidades de seu serviço, se você está lhe dando com dados sensíveis como (cadastros de pessoas, contas bancárias, resumos financeiros), você precisa de uma autenticação oAuth e que sua API descanse em um protocolo HTTPS.
Como definir então API em formato REST?

Isso é assunto para os próximos 2 artigos que serão publicados aqui, mostrando como criar um REST em serviços JAVA usando o Jersey com padrão de design JAX-RS, implementando REST com PHP usando um framework simples o Slim Framework.