BT

Características de Design de Um Framework Orientado a Recurso

por Dilip Krishnan , traduzido por Marcus Rehm em 17 Jun 2009 |

Dhananjay Nene, que também escreveu um ótimo artigo sobre a história do REST, examina várias características que são esperadas dentro da modelagem de um Framework Orientado a Recurso (Resource Oriented Framework ou ROF). O artigo também tenta capturar o relacionamento do modelo de negócio de uma aplicação e seu modelo de recurso.

De acordo com Dhananjay, algumas dessas características são evidentes devido a popularidade de alguns destes frameworks como Struts, Django, Ruby on Rails etc. No entanto, enumerando-as pode-se definir as causas do sucesso e popularidade destes frameworks. Exemplos dessas características são

Um ROF deve ter uma abstração para representar um recurso como um ponto de acesso

Se eu estivesse usando uma Ordem como um recurso e se introduzisse um método de aprovação no OrdemControlador isso não seria coerente com os requerimentos. Neste caso, deve-se modelar um recurso AprovaçãoOrdem o qual após executar, deve refletir uma troca de estado para "Aprovado" no recurso Ordem.

Dadas as considerações consistentes das Operações dos Recursos, a implementação será facilmente atingida

Um ROF deve prover suporte adicional para aspectos típicos do ciclo de vida (Ex. validação)

Os métodos do contrato (interface) do recurso devem ser implementados implicitamente pelo framework [e] o framework deve permitir o desenvolvedor "plugar" / sobrescrever com sua própria implementação [e suportar tarefas como validação].

Um ROF deve prover a possibilidade do desenvolvedor sobrescrever ou registrar métodos para tratamento dos impactos das ações PUT, POST e DELETE

Eu criei uma analogia onde um sistema baseado em REST é como um DBMS onde aplicações clientes podem fazer consultas SQL como SELECT, INSERT, UPDATE, DELETE (GET, PUT, POST, DELETE no caso HTTP/REST) nas tabelas (Recursos no caso de REST), e as regras de negócio são implementadas em "triggers" (gatilhos).

Um ROF deve prover um mecanismo para descrever ou mapear a abstração de um recurso num objeto de negócio

Existem inúmeras formas de se fazer isso. XML, YAML, DSL, Annotation - faça sua escolha. Além disso, a classe pode ser definida (no caso de uma POJO) e as características do recurso mapeadas nela, ou a classe pode manifestar estas características em tempo de execução baseada na metaprogramação em torno dos metadados. Assim o framework permitirá relacionamentos serem descritos ou inferidos.

Um ROF permitirá a representação de chaves estrangeiras através de URIs (Unified Resource Identifier) em referência de objetos de negócio

Recursos se referenciam através de URIs. Os objetos na camada de negócio referem uns aos outros utilizando referências de memória. Dadas as descrições e mapeamentos das URIs, o framework deverá permitir uma transparência ao referenciar / desreferenciar as URIs e as referências de memória.

Enquanto muitas das facetas de um ROF parecem naturais para serviços REST, algumas características necessitam de mais explicações ou análise.

Um ROF deve permitir "factory methods" para localização ou injeção de dependência de outros recursos / objetos de negócio

O desenvolvedor poderá escolher entre interagir no nível de recurso ou mais a fundo no nível de objetos de negócio. O framework deverá dar suporte necessário para estas atividades.

Um ROF deve permitir que os recursos / descrição das mídias sejam enviadas através do mesmo canal que as representações (conteúdo) dos recursos: Já que o REST permite que os tipos de mídia sejam descobertos e descritos de forma independente, o framework deve permitir que os metadados dessas mídias sejam disponibilizados para o cliente. Os metadados podem ser representados através de qualquer padrão como RDFa, XML Schema, etc.

Embora as facetas que Dhananjay cita sejam de fácil entendimento, o artigo não cobre alguns dos requisitos não funcionais tais como suporte a monitoramento, auditoria / logging, gerenciamento de transações.  Leia o artigo original para mais detalhes.

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
Comentários da comunidade

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

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