Image Image Image Image Image
Scroll to Top

Topo

rest

27

abr
2012

Sem Comentários

Em .NET
Blog
REST

Por Allison

Desenvolvimento de Web APIs evolui no ASP.NET MVC 4

Em 27, abr 2012 | Sem Comentários | Em .NET, Blog, REST | Por Allison

Fonte: Elemar Jr./InfoQ

A nova versão do framework para desenvolvimento de aplicativos Web da Microsoft, o ASP.NET MVC 4, amplia muito o suporte ao desenvolvimento de aplicações Web API. O framework, agora integralmente open source e disponível no Codeplex, possibilita o desenvolvimento de serviços RESTful com pouco esforço.

Entre as novidades na versão 4, destacam-se a facilidade para criar rotas para recursos (evitando colisão com rotas padrões MVC), a escrita de Actions para cada um dos métodos HTTP, o suporte nativo ao fornecimento de objetos em formato JSON e XML, além do suporte ampliado a URLs de consulta compatíveis com OData.

O ASP.NET MVC Web API permite um novo modelo de desenvolvimento web, em que o servidor provê apenas conteúdo e a geração da apresentação ocorre inteiramente no browser. Ou seja, no lugar de prover o HTML pronto, o servidor pode entregar um composto HTML + JavaScript, deixando que os dados sejam requisitados conforme demanda, via Ajax, para um serviço RESTful. (Importante destacar que o template padrão para aplicações ASP.NET MVC já possui referências para JQuery.) A possibilidade de gerar, automaticamente, respostas em formato JSON facilita consideravelmente a manipulação de código JavaScript.

As novas funcionalidades já são suportadas tanto no novo Visual Studio 11 (ainda beta e disponível para download na versão Ultimate), quanto no Visual Studio 2010 (mediante instalação).

Conforme noticiamos aqui, embora o ASP.NET MVC 4 não esteja completo, a Microsoft já recomenda sua utilização em produção. A Microsoft disponibilizou um mini-tutorial sobre o framework, com artigos e vídeos.

Tags | , , , , , , ,

02

dez
2011

Sem Comentários

Em Blog
Java
Testes

Por Allison

Restfuse 1.0.0: uma biblioteca para facilitar testes de integração REST/HTTP

Em 02, dez 2011 | Sem Comentários | Em Blog, Java, Testes | Por Allison

A EclipseSource lançou a primeira versão estável de uma extensão open souce do JUnit para automação de testes de serviços REST/HTTP. O Restfuse é um conjunto de anotações para JUnit que oferece asserções para respostas de requisições HTTP. Tanto chamadas síncronas como assíncronas são suportadas.

O Restfuse já está disponível no Maven Central, então para usá-lo não é necessário nenhum repositório especial:

<dependency>
<groupId>com.restfuse</groupId>
<artifactId>com.eclipsesource.restfuse</artifactId>
<version>1.0.0</version>
</dependency>

Usar a biblioteca para chamadas síncronas é simples e direto:

@RunWith(HttpJUnitRunner.class)
public class RestFuseTest {
@Rule
public Destination destination = new Destination("http://example.com" );

@Context
private Response response; // será injetado depois de cada chamada
@HttpTest(method = Method.GET, path = "/reloadLocalConfiguration" )
public void checkRestfuseOnlineStatus() {
assertOk(response );
String answerBody = response.getBody(String.class);
assertEquals("Expected correct response","done",answerBody);
}
}

O teste acima chama um endereço HTTP de maneira síncrona e então valida se há uma resposta textual (text/plain) contendo a string “done”. Note que a primeira asserção, assertOk, é do Restfuse; ela verifica se o status da resposta HTTP foi 200 OK. A segunda asserção, assertEquals, verifica a igualdade como no JUnit. Embora esteja se supondo que o endereço HTTP vai retornar um texto puro, poderia também ser processado conteúdo em JSON/XML ou de outro tipo, e executar os asserts de maneira estruturada.

O Restfuse também suporta chamadas assíncronas. Uma aplicação clássica disso se dá em operações de longa duração (como o upload de um arquivo extenso), em que o cliente monitora continuamente o servidor para identificar o status atual. No exemplo abaixo, é considerado um endereço do lado servidor que retorna um número entre 0 e 100 e mostra o progresso de alguma operação:

@RunWith( HttpJUnitRunner.class )
public class PollTest1 {

@Rule
public Destination destination = new Destination( "http://example.com" );

@Context
private Response response;

@Context
private PollState pollState;

@HttpTest( method = Method.GET, path = "/progressStatus" )
@Poll( times = 5, interval = 500 )
public void testAsynchronousService() {
if(pollState.getTimes() == 5)
{
String answerBody = response.getBody(String.class);
assertEquals("Expected last response","100",answerBody);
}
}
}

O teste acima chama o mesmo endereço cinco vezes (com um intervalo definido), mas somente a última chamada verifica a resposta HTTP.

Uma característica interessante da interface PollState é a manutenção das respostas anteriores. Isto permite aos asserts sejam feitos sobre o histórico das chamadas:

@RunWith( HttpJUnitRunner.class )
public class PollTest2 {

@Rule
public Destination destination = new Destination( "http://example.com" );

@Context
private Response response;

@Context
private PollState pollState;

@HttpTest( method = Method.GET, path = "/progressStatus" )
@Poll( times = 5, interval = 500 )
public void testAsynchronousService() {
int currentRun = pollState.getTimes();
if(currentRun > 1)
{
String previousProgress = pollState.getResponse(currentRun - 1).getBody(String.class);
String presentProgress = response.getBody(String.class);
assertTrue("Expected some progress",Integer.parseInt(presentProgress) > Integer.parseInt(presentProgress)); //Just for illustration purposes
}
}
}
}

O teste acima verifica se cada resposta tem número superior à resposta anterior. O Restfuse tem uma dependência com o servidor HTTP Jetty e suporta serviços assíncronos que seguem o modelo de Web Hooks. Ao invés de enviar várias requisições ao servidor para verificar o estado de um processo, o cliente cliente faz uma chamada uma única vez e então aguarda por uma resposta iniciada pelo servidor em uma conexão diferente. Aqui está um exemplo usando Restfuse:

 
@RunWith( HttpJUnitRunner.class )
public class RestfuseCalbackTest {

@Rule
public Destination destination = new Destination( "http://example.com" );

@Context
private Response response;

private class TestCallbackResource extends DefaultCallbackResource {

@Override
public Response post( Request request ) {
assertTrue("Expected a quote response", request.getBody(String.class).startsWith("quote:") );
return super.post( request );
}
}

@HttpTest( method = Method.GET, path = "/requestQuote" )
@Callback( port = 9090, path = "/asynchron", resource = TestCallbackResource.class, timeout = 10000 )
public void testMethod() {
assertAccepted( response );
}
}

Este último exemplo conecta-se ao requestQuote e monitora a porta 9090 do cliente. Durante até dez segundos, ele espera uma resposta textual, começando com “quote:”

Para mais informações sobre o Restfuse, visite a wiki do projeto e seu Javadocs. O código-fonte esta hospedado no GitHub.

Fonte: Kostis Kapelonis , traduzido por Jefferson Prestes /InfoQ

Tags | , , , , , , ,

23

nov
2011

Sem Comentários

Em Arquitetura
Blog
NoSQL
REST

Por Allison

REST tem impacto sobre NoSQL?

Em 23, nov 2011 | Sem Comentários | Em Arquitetura, Blog, NoSQL, REST | Por Allison

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?

Fonte: Mark Little , traduzido por Lucas Machado/InfoQ

Tags | , , ,

29

out
2011

Sem Comentários

Em Blog

Por Allison

REST tem impacto sobre NoSQL?

Em 29, out 2011 | Sem Comentários | Em Blog | Por Allison

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?

Fonte: Mark Little/Lucas Machado

Tags | , , , , ,