BT
x Por favor preencha a pesquisa do InfoQ !

Trabalhando com Operações Assíncronas REST.

por Boris Lublinsky , traduzido por Rafael Riberto em 04 Ago 2009 |

Em seu novo post – Slow REST Tim Bray tenta responder a seguinte questão:

Em um contexto RESTful, como se lida as operações de mudança de estado (POST, PUT, DELETE) que possuem latência substancial e imprescindível?

Tim descreve três abordagens diferentes para esta situação, desenvolvidas como parte do Project Kenai na forma de uma proposta – Trabalhando Operações de Requisições Assíncronas. Estas abordagens incluem:

  • Abordagem baseada em recursos que têm:
    Um novo modelo de recurso "Status "..., com os seguintes campos:
    • "uri "– URI no qual o cliente pode executar operações GET para sondar para conclusão. Cada operação assíncrona aceita receberá um único status URI, então múltiplas operações podem ser iniciadas e acompanhadas em uma vez.
    • "status" – Código integer descrevendo o status de conclusão (0=sucesso, nonzero= código de erro), devolvido apenas quando “progresso” retorna 100.
    • "message" – Mensagem ajustado para relatar o estado de conclusão para o usuário humano, retornado somente quando o “progress” retorna 100.
    • "progress" – Indicador de percentual complet, o qual deve retornar 100 somente quando a operação foi completada (com ou sem o sucesso).
    Este objeto de recurso pode ser usado da seguinte forma:
    Para toda e qualquer operação PUT/POST/DELETE, devolvemos “202 em andamento” e um objeto “Status” ,... designado para possibilitar que desenvolvedores tornem fácil de monitorar.
  • Implementação relâmpago – mantendo o canal HTTP aberto para o tempo de um request de longa duração.
    • A resposta HTTP inicial DEVE conter o status 202 (“Accepted”)... e todo o corpo contendo o objeto Status inicial para esta operação. Neste objeto, os campos “uri” e “progress” DEVEM ser populados, e o campo “progresso” DEVE conter o valor 0 (zero) indicando que a operação está começando.
    • O valor URI devolvido na resposta inicial DEVEM responder para requisições GET devolvendo uma versão alterada do objeto Status. Normalmente, o campo “progress” crescerá até 100, porém, NÃO PODE ser definido como 100 até que a operação termine.
    • Quando a operação terminar (com ou sem sucesso), uma representação final do objeto Status DEVE ser retornada, com o campo “progress” igual a 100, e o campo “status” igual 0 (zero) para término com sucesso ou um outro valor para término sem sucesso.
  • "Web hooks" – usando duas invocações de uma via independente – uma para iniciar uma operação de longa duração e outra para notificar o requisitante que está terminada.
    • A representação de entrada da requisição da operação PODE conter um campo “webhook”, cujo valor é um URI onde o cliente espera uma chamada de volta. Se este campo não está presente, nenhum retorno “webhook” será executado.
    • Quando a operação termina (com ou sem sucesso), o servidor executará uma requisição POST para o URI do “webhook”, com... um entity que contém o objeto Status final desta operação
    • O cliente pode comparar o aviso de término com a requisição original, comparando o valor do campo “uri” com o retornado no Status inicial, ou provendo um webhook URI único para cada requisição assíncrona.

Tim finaliza seu post abordando:

… “Slow REST” é um padrão que aparecerá demais novamente no futuro quando deveríamos pensar em uma receita padronizada para abordá-lo.

Seu post ocasionou diversas respostas, uma em particular de William Vambenepe ,compara os problemas e soluções propostos por Tim com os definidos nos padrões WS*, especificamente WSRF e WS-Notifications. De acordo com William:

WSFR chega a cobrir este caso de uso (slow create), mas entre WS-ResourceLifetime e WS-Notification se vê alguns casos de uso similares no trabalho (qual BTW você poderá executar na seqüência). Soma-se este WS-MakeConnection (parte do WS-RX), sua idéia de “webhooks” se torna muito mais prática... Eu sempre tive a intuição que “REST” e “WS-(Death)Star” se tornariam mais próximas.

Apesar das muitas diferenças (algumas reais, algumas “religiosas”) entre REST e WS*, ambos miram em resolver problemas reais do dia-a-dia e, conseqüentemente, enfrentam os mesmos desafios. Aprendendo experiências e implementações uma da outra irá definitivamente melhorar ambas.

Avalie esse artigo

Relevância
Estilo/Redação

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 mensagens dessa discussão
Comentários da comunidade

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

Receber mensagens dessa discussão

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

Receber mensagens dessa discussão

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

Percebemos que você está utilizando um bloqueador de propagandas

Nós entendemos porquê utilizar um bloqueador de propagandas. No entanto, nós precisamos da sua ajuda para manter o InfoQ gratuito. O InfoQ não compartilhará seus dados com nenhum terceiro sem que você autorize. Procuramos trabalhar com anúncios de empresas e produtos que sejam relevantes para nossos leitores. Por favor, considere adicionar o InfoQ como uma exceção no seu bloqueador de propagandas.