CRUD Combina com REST?

Postado por Boris Lublinsky , traduzido por Samuel Carrijo em 07 Ago 2009

Seções

Arquitetura Corporativa,

Arquitetura e Design

Tópicos

SOA ,

REST ,

Design ,

Arquitetura

Tags

Service Design

Arnon Rotem-Gal-Oz inicia seu post  "CRUD é ruim para o REST", afirmando:

Analisando superficialmente, parece que os dois combinam (tanto tecnicamente quanto arquiteturalmente), porém se aprofundarmos a análise um pouquinho, veremos que isso não é verdade em nenhum dos dois aspectos.

Hoje, a implementação mais comum do estilo arquitetural REST é baseado no protocolo HTTP e, consequentemente, nos verbos do HTTP: POST, GET, PUT e DELETE. É comum desenvolvedores implementarem esses verbos mapeando-os em termos CRUD - Create, Read, Update e Delete (Criar, Ler, Atualizar e Excluir). Um mapeamento típico é de 1 para 1:

• o verbo GET normalmente é mapeado para o CRUD Read (Leitura), embora o GET forneça algumas funcionalidades a mais do que um mapeamento SELECT padrão.
• o verbo DELETE normalmente é mapeado para o CRUD Delete (Excluir).
• o verbo PUT normalmente é mapeado para CRUD Update (Atualizar), mas com algumas ressalvas:
  • O PUT requer um recurso substituto completo, enquanto no Update o recurso pode ser parcial.
  • O PUT pode ser usado para criar um recurso (quando a URI é definida pelo cliente)
• o verbo POST é normalmente mapeado para o CRUD Create (Criar) mas ele só dá suporte à criação de um recurso filho. O POST também pode ser usado para realizar atualização parcial de um recurso.

Na opinião de Arnon:

Os verbos HTTP são mais orientadas a documentos do que orientandos a bancos de dados - enquanto você pode atualizar, excluir e criar novos recursos, isso não é exatamente CRUD no "sentido banco de dados" da palavra - pelo menos quando se trata de utilizar verbos HTTP.

Mas o maior motivo pelo qual o CRUD não é um paradigma adequado para REST é arquitetural. O coração de REST é a implementação da máquina de estados do protocolo utilizando hipermídia. Arnon cita Tim Ewald:

... E eis o que passei a entender. Todo protocolo de comunicação tem uma máquina de estados. Em alguns protocolos ela é muito simples, em outros ela é mais complexa. Quando você implementa um protocolo via RPC, você cria métodos que modificam o estado da comunicação. Esse estado é mantido como uma caixa preta na outra extremidade. Devido ao estado do protocolo estar escondido, é mais fácil entender as coisas do jeito errado. Por exemplo, você pode chamar o Process antes de chamar o Init. As pessoas têm procurado formas de evitar estes problemas por um longo período de tempo através de anotações de informações sobre o tipo da interface, mas eu não conheço nenhuma solução largamente adotada. O fato de o estado do protocolo estar encapsulado por trás das chamadas a métodos que modificam esse estado de maneiras não-óbvias, o versionamento passa a ser algo interessante.

A essência do REST é tornar os estados do protocolo explícitos e endereçáveis através de URIs. O estado atual da máquina de estados do protocolo é representada pela URI chamada e da representação do estado que você obteve. Você pode alterar o estado fazendo uma chamada à URI do estado desejado. A representação de um estado inclui as ligações com os outros estados para os quais pode mover a partir do estado atual. É exatamente assim que aplicativos baseados em navegador funcionam, e não há nenhuma razão para que o protocolo do seu aplicativo não pode trabalhar dessa mesma maneira. (O protocolo de publicação ATOM é o exemplo canônico, embora seja fácil pensar que a essência dele são as entidades, e não uma máquina de estados.)

Seguido do artigo de John Evdemon, explicando por que serviços do tipo CRUD são um anti-padrão SOA, Arnon explica as desvantagens do CRUD REST:

• Ele contorna toda a ideia de "Serviços" - não há lógica de negócios.
• Ele expõe a estrutura interna dos dados ou do banco de dados ao invés de um contrato bem elaborado.
• Favorece a ideia de ignorar os serviços de verdade e partir direto para os seus dados.
• Ele cria uma serviço (a fonte de dados) que é uma bolha.
• Favorece a criação de "semi-serviços" (as várias "interfaces" dessa bolha) que ignoram alguns aspectos de computação distribuída.
• É a arquitetura cliente-servidor em pele de cordeiro.

Arnon termina o seu post reenfatizando que apenas a adoção de padrões como HTTP, XML, JSON (embora possa ser útil) não constitui REST - é necessário adotar a arquitetura REST.

Esse post é um importante lembrete de que REST, assim como SOA, não é um conjunto de padrões e APIs populares, mas sim um paradigma arquitetural, que deve ser compreendido e seguido.

• Mais antigos >