BT

CRUD Combina com REST?

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

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.

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

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.