Conversações de Negócio RESTful

Em uma série de artigos intituladas de Os diálogos REST, Duncan Cragg “discute o case para o eBay de adotar uma abordagem verdadeiramente REST para sua API de integração”; Em “Business conversations”, Duncan faz um case de negócio para a adoção de uma arquitetura baseada em REST.

 Duncan explica, em um estilo conversacional, para uma arquitetura fictícia do eBay, que uma abordagem RESTful é simples, e mais poderosa, em uma arquitetura de processos de negócio do que uma construção SOA utilizando as especificações WS-*. No papel de um arquiteto de aplicação, ele explica:

 É o seu trabalho enquanto ele esta desenhando as interações dos recursos no nível da aplicação: o tipo de recurso ou nível do negócio. Ou talvez enquanto [ele ] está fazendo uso de alguns tipos de recursos existentes e código de ‘animação-de-recurso’ que faz [sua] lógica de negócio para você. WS-* somente complica esta tarefa.

“Quando você começa a pensar em termos de recursos e não ações, tudo se torna muito mais claro”, Duncan explica conforme ele aborda aspectos como Service Discovery e Descrição, Estado de Cliente, Sessões e Processos de Negócio em uma arquitetura orientada a recurso (ROA). Ele afirma que

 É melhor iniciar com um baixo acoplamento e convenções estabelecidas; e adicionar regras, contratos e Central de Controle somente quando for absolutamente necessário.  Assegurar controle central sobre schemas.

 Torne sua Empresa ‘orquestrável’ e todos irão lhe agradecer. Exponha os UUIDs dos seus dados em URLs. Transforme e enriqueça seus dados em tipos de conteúdo padrão.

Ao gerenciar o estado do cliente em dada arquitetura ele alerta que

 [Qualquer] Estado escondido é um sinal vermelho. Você sabe que está no caminho correto quando está expondo seus estados em URIs. [...] Se você se ver escondendo estado em sessões e cookies, ou retornando dados diferentes dedicados ao cliente da mesma URI setando no-cache, ou se você vincular interações sucessivas através de sessões, você esta indo para o lado errado.

Ele reconhece que tal abordagem pode ser difícil de vender em uma empresa, mas afirma que isto "se mapeia mais próximo à realidade da maneira que os negócios operam e interoperam".

 REST […] mapeia naturalmente as regras declarativas de negócio. Quando você troca de pensamente-em-processo por persamento-em-recurso, você também troca de pensamento-imperativo para declarativo. Ao invés de coordenar a importação e exportação de dados de uma interface codificada manualmente para outra, você pode somente lincar tudo e esperar que todos se referenciem e reconhecam seus dados.