BT

REST tem impacto sobre NoSQL?

por Mark Little , traduzido por Lucas Machado em 22 Out 2011 |

A partir do momento que grandes empresas como o Twitter e a Amazon abraçaram a arquitetura REST e também se tornaram defensores do NoSQL tornou-se inevitável assistirmos a essas duas tecnologias sendo utilizadas em conjunto. Em um post recente, Ganesh Prasad questiona como o sucesso do NoSQL nos leva a reavaliar os aspectos centrais do REST. Ganesh acredita que existem dois aspectos na tecnologia que representam obstáculos para a sua adoção:

Um deles é o uso do modelo cliente/servidor, ao invés do modelo de ponto a ponto, que  acredito ser mais geral e útil. O segundo é a insistência na ausência de estado do cliente no servidor, forçando que essas informações sejam armazenadas no próprio cliente ou que sejam modeladas como recursos.

É no aspecto da ausência de estado que Ganesh se concentra. A questão de manutenção de estado e o REST já foi muito debatida em várias fontes, por exemplo Bill Burke discutiu essa questão anos atrás:

Em REST, a ausência de estado significa que não existem dados da sessão do cliente armazenados no servidor. O servidor somente cuida do estado dos recursos que expõe. Se houver necessidade de informações específicas da sessão de algum cliente, essas informações devem ser armazenadas no próprio cliente e transferidas para o servidor a cada requisição, quando necessário.

A camada de serviços que não mantém informações dos clientes conectados é muito mais simples de escalar, por precisar de menos informações ao se replicar em um ambiente em cluster. É mais simples de colocar em cluster, porque tudo o que é preciso fazer é adicionar mais máquinas.

Stefan Tilkov adota a mesma linha:

É importante reforçar que, embora REST inclua a ideia da ausência de estado, isso não significa que a aplicação que expõe suas funcionalidades não pode ter estado – isso tornaria essa abordagem pouco útil para a maioria dos cenários. 

O REST obriga que o estado seja transformado em um recurso ou mantido no cliente. Em outras palavras, o servidor não deve manter nenhum tipo de informação associada ao estado da comunicação com o cliente, independente do da duração de uma requisição. A principal razão para isso é a escalabilidade: a capacidade de atendimento dos servidores fica severamente prejudicada quando o servidor necessita manter o estado das comunicações. (Note que essa restrição exige modificações na aplicação: não se pode simplesmente atribuir uma URI a um estado da sessão e chamar a aplicação de RESTful.)

Existem outros aspectos mais importantes: a ausência de estado isola o cliente de alterações dos servidores, uma vez que não depende da comunicação com o mesmo servidor em duas requisições consecutivas. O cliente pode receber um “documento” contendo links de um servidor e, enquanto o cliente processa essas informações, o mesmo servidor pode ser desligado; o disco removido e trocado; e o software atualizado e reiniciado; tudo isso sem impacto negativo. Se o cliente seguir os links obtidos a partir do servidor, ele não irá perceber.

Ganesh, apesar de entender que a ausência de estado colabora com demandas de escalabilidade e recuperação a falhas, acredita que tais restrições sobrecarregam a camada da aplicação, que passa a ter de tratar aspectos de distribuição e infraestrutura:

A abordagem REST é aceitável para elementos do domínio da aplicação, mas a existência de estado de comunicação com o cliente é útil para tratar elementos independentes do domínio, associados à qualidade do serviço como, por exemplo chaves de sessão para o controle de segurança. A recusa do REST em suportar aspectos como esses compromete a habilidade de oferecer essas características de forma transparente.

É para esse tipo de estado referenciado por Bill e Stefan que Ganesh chama atenção. Ganesh destaca que o NoSQL oferece uma solução escalável e tolerante a falhas para o problema. Ele se refere à implementação do Redis, entretanto a maioria (se não todas) as implementações NoSQL também tratam deste problema.

Está se tornando uma recomendação armazenar o estado da sessão em um banco de dados NoSQL como o Redis, ao invés de em memória. Delegar o armazenamento dos dados de sessão para um cluster NoSQL independente, e configurar os servidores de aplicação para obtê-las a partir deste cluster, torna os servidores de aplicações independentes dos clientes novamente. Um destaque no Redis é a baixa complexidade das operações GET e SET, que são de Ordem(1), ou seja, constante. Isto significa que (pelo menos em teoria) o número de clientes utilizando um banco de dados Redis pode aumentar indefinidamente, sem impacto na performance.

O artigo de Ganesh descreve como podemos utilizar o banco de dados NoSQL Redis para gerenciar os dados de sessão. Desta forma, acredita ele, aplicações REST devem ser levadas seriamente em consideração (neste caso sendo necessário atualizar/aprimorar a filosofia do REST). Ele conclui dizendo:

Seria bom se um mecanismo padrão e sem dependência de domínio pudesse evoluir para fornecer segurança e confiabilidade às interações baseadas em REST, utilizando mecanismos de armazenamento escalável de sessões em NoSQL.

A maioria das metodologias de desenvolvimento, frameworks e padrões mantém a sua relevância evoluindo para novas abordagens, assim que novas experiências são obtidas. NoSQL era apenas um exercício acadêmico quando a arquitetura REST foi proposta, portanto surge a questão: a arquitetura REST precisa evoluir face ao NoSQL, ou a natureza sem estado do REST continua a ser uma exigência, independentemente da abordagem utilizada para armazená-lo?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Estado x recursos by Luiz Fernando Oliveira Corte R...

A natureza sem estado do REST não impede, a meu ver, que tenhamos sessões específicas por cliente. Basta que cada sessão, cada recurso específico de um cliente, seja visto como um recurso como qualquer outro da aplicação, que você pode criar, atualizar e destruir.

A meu ver, bancos de dados NoSQL não revolucionam o modo de ver REST ou exigem uma remodelagem dessa arquitetura, apenas são uma ferramenta eficiente para armazenar esses recursos. Nada que já não pudesse ser feito com bancos de dados relacionais.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

1 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT