Diferença entre REST e CRUD


168

Eu aprendi REST e parece muito com CRUD (pelo que li sobre CRUD).

Eu sei que eles são diferentes, e me pergunto se pensar que são semelhantes significa que eu não os entendo.

O REST é um "superconjunto" do CRUD? Tudo o que o CRUD faz e muito mais?


17
Pensar que eles são semelhantes significa que você os entende. Ao ler as respostas, vejo um nível surpreendente e que considero incorreto de não reconhecer as semelhanças entre os conceitos. Eu acredito que a maneira correta de entender o REST é pensar nele como "CRUD para recursos HTTP". Se você entende o que é um recurso HTTP (não é o mesmo que um registro do banco de dados obviamente) e sabe o que é CRUD, descrever o REST como "CRUD para recursos HTTP" é uma maneira correta e sucinta de transmitir a essência do REST.
Jason Livesay

Respostas:


205

Surpreendentemente, não vejo nas outras respostas o que considero a diferença real entre REST e CRUD: o que cada um gerencia.

CRUD significa as operações básicas a serem realizadas em um repositório de dados. Você lida diretamente com registros ou objetos de dados; além dessas operações, os registros são entidades passivas. Normalmente, são apenas tabelas e registros de banco de dados.

O REST, por outro lado, opera em representações de recursos, cada uma identificada por uma URL. Normalmente, esses não são objetos de dados, mas abstrações complexas de objetos.

Por exemplo, um recurso pode ser o comentário de um usuário. Isso significa não apenas um registro em uma tabela de 'comentários', mas também seus relacionamentos com o recurso 'usuário', a postagem à qual o comentário está anexado, talvez outro comentário ao qual ele responda.

Operar no comentário não é uma operação primitiva do banco de dados, pode ter efeitos colaterais significativos, como disparar um alerta para o pôster original ou recalcular alguns 'pontos' semelhantes a jogos ou atualizar alguns 'fluxos de seguidores'.

Além disso, uma representação de recurso inclui hipertexto (verifique o princípio HATEOAS ), permitindo ao designer expressar relacionamentos entre recursos ou guiando o cliente REST no fluxo de trabalho de uma operação.

Em suma, CRUD é um conjunto de operações primitivas (principalmente para bancos de dados e armazenamento de dados estáticos), enquanto o REST é um estilo de API de nível muito alto (principalmente para serviços da Web e outros sistemas "ativos").

O primeiro manipula dados básicos, o outro interage com um sistema complexo.


3
@Javier Obrigado por separá-los. Eu usei o REST learning Rails e tive a impressão de que era um substituto para o CRUD (sobre o qual aprendi desde ... o nome, ou seja, eu já estava usando, mas não sabia como chamá-lo) ... Você virou REST vs CRUD de comparar 2 maçãs para comparar maçãs e laranjas. Obrigado
Jesse Black

2
@ Maudicus: eu acho que é muito comum, já que o RoR inclui uma camada CRUD (como a maioria (toda?) Estrutura) faz, e facilita (automático?) Adicionar uma API REST sobre isso, é fácil pensar que é tudo o que é REST. Porém, você pode adicionar funcionalidades sobre o CRUD, mas atrás da API REST, tornando-as cada vez mais diferentes.
Javier

1
Sua resposta está correta, mas o exemplo não é o ideal: um comentário pode se resumir a uma única linha de banco de dados e não é possível implementar alterações dinâmicas em objetos relacionados com gatilhos de banco de dados? Eu sinto que há um pouco mais do que apenas operações grosseiras em APIs repousantes, e sua resposta claramente leva essa sensação bem.
didierc

2
Então ... mesma coisa, camada diferente :)
AlikElzin-Kilaka

Muito obrigado por expressar isso! Eu acrescentaria que a limitação de verbos HTTP para operações CRUD resulta na implementação REST literalmente como CRUD, com muitas ferramentas que generalizam o padrão CRUD e perdem um lugar para essa lógica "operacional em um comentário" personalizada.
Sompylasar

99

Primeiro de tudo, ambos são simplesmente iniciais comuns; eles não são nada a temer.

Agora, CRUD é um termo simples que foi abreviado porque é um recurso comum em muitos aplicativos e é mais fácil dizer CRUD . Descreve as 4 operações básicas que você pode executar nos dados (ou em um recurso). Criar, Ler, Atualizar, Excluir.

O REST, no entanto, é uma prática nomeada (assim como o AJAX), não uma tecnologia em si. Ele incentiva o uso de recursos que há muito tempo são inerentes ao protocolo HTTP, mas raramente usados.

Quando você tem um URL (Uniform Resource Locator ) e aponta o navegador para ele pela linha de endereço, está enviando uma solicitação HTTP . Cada solicitação HTTP contém informações que o servidor pode usar para saber qual resposta HTTP enviar de volta ao cliente que emitiu a solicitação.

Cada solicitação contém uma URL, para que o servidor saiba qual recurso você deseja acessar, mas também pode conter um método . Um método descreve o que fazer com esse recurso.

Mas esse conceito de "método" não era usado com muita frequência.

Geralmente, as pessoas simplesmente vinculam as páginas através do método GET e emitem qualquer tipo de atualização (exclusões, inserções, atualizações) através do método POST.

E, por isso, não foi possível tratar um recurso (URL) como um recurso verdadeiro por si só. Você precisava ter URLs separados para exclusão, inserção ou atualização do mesmo recurso. Por exemplo:

http://...com/posts/create- POST request  -> Goes to posts.create() method in the server
http://...com/posts/1/show- GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1/delete - POST request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1/edit- POST request  -> Goes to posts.edit(1) method in the server

Com o REST, você cria formulários mais inteligentes porque usa outros métodos HTTP além do POST e programa seu servidor para poder distinguir entre métodos , não apenas URLs. Então, por exemplo:

http://...com/posts - POST request  -> Goes to posts.create() method in the server
http://...com/posts/1 - GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1 - DELETE request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1 - PUT request  -> Goes to posts.edit(1) method in the server

Lembre-se, um único URL descreve um único recurso. Uma única postagem é um único recurso. Com o REST, você trata os recursos da maneira que eles deveriam ser tratados. Você está dizendo ao servidor qual recurso você deseja manipular e como manipulá-lo.

Existem muitos outros recursos na "arquitetura RESTful", sobre os quais você pode ler na Wikipedia, em outros artigos ou livros, se estiver interessado. Por outro lado, não há muito mais no próprio CRUD.


4
Desculpe, mas o REST é muito mais que o CRUD. principalmente porque os recursos incorporam muito mais do que um único registro cada, e cada operação faz muito mais do que atualizar um registro.
Javier

11
Está bem. Concordo. Por que você está arrependido? Eu não disse que não era muito mais que CRUD. Eu acho que é exatamente o que eu queria dizer.
Yam Marcovic

4
Essa deve ser a resposta certa.
Brandon

A especificação HTML permite apenas os métodos GET e POST para envio de formulários, portanto os outros métodos não foram usados ​​nos serviços que manipulam solicitações de clientes da Web antes que o AJAX se espalhe. Alguns serviços usam um campo de entrada oculto com o nome "_method" como solução alternativa para especificar um método diferente de POST enquanto ainda envia o formulário usando o método POST.
Kenneth Sundqvist 24/09

20

REST significa "transferência de estado representacional", o que significa que se trata de comunicar e modificar o estado de algum recurso em um sistema.

O REST se envolve bastante, porque a teoria por trás do REST aproveita a mídia, a hipermídia e um protocolo subjacente para gerenciar informações em um sistema remoto.

O CRUD, por outro lado, é um mnemônico para as operações comuns necessárias para os dados em um banco de dados: Criar Excluir Recuperar Atualização. Mas isso realmente não é mais profundo do que isso.

Essa é a resposta para sua pergunta, mas mencionarei o erro comum que vejo quando REST e CRUD são discutidos juntos. Muitos desenvolvedores desejam mapear REST para CRUD diretamente, porque REST sobre HTTP fornece GET PUT POST e DELETE, enquanto CRUD fornece CREATE RETRIEVE UPDATE DELETE. É natural querer mapear os verbos REST diretamente para operações CRUD.

No entanto, o HTTP usa um estilo "criar ou atualizar", enquanto o CRUD separa criar e atualizar. Isso torna impossível (!) Fazer um mapeamento geral e limpo entre os dois (!)

GET e DELETE são fáceis ... GET === RECUPERAR e DELETE === DELETE.

Mas, de acordo com a especificação HTTP, PUT é realmente Create AND Update:

  • Use PUT para criar um novo objeto quando souber tudo sobre ele, incluindo seu identificador

  • Use PUT para atualizar um objeto (geralmente com uma representação completa do objeto)

POST é o verbo "processing" e é considerado o verbo "anexar":

  • Use o POST para anexar um novo objeto a uma coleção - ou seja, crie um novo objeto

  • POST também é usado quando nenhum dos outros verbos se encaixa perfeitamente, pois a especificação HTTP o define como o verbo "processamento de dados"

  • Se sua equipe está ficando desconectada do POST, lembre-se de que toda a WWW foi criada no GET e no POST;)

Portanto, embora haja semelhança entre REST e CRUD, o erro que vejo a maioria das equipes é fazer uma equivalência entre as duas. Uma equipe realmente precisa ter cuidado ao definir uma API REST para não ficar muito desligada no mnemônico CRUD, porque o REST, como prática, realmente tem muita complexidade adicional que não é mapeada corretamente para o CRUD.


7

CRUD especifica um conjunto mínimo de verbos básicos de armazenamento para leitura e gravação de dados: criar, ler, atualizar e excluir. Em seguida, você pode criar outras operações agregando-as. Geralmente, são consideradas operações de banco de dados, mas o que é considerado um banco de dados é arbitrário (por exemplo, pode ser um DBMS relacional, mas também pode ser arquivos YAML).

REST é um "estilo arquitetural" que geralmente inclui operações CRUD e outras operações de nível superior, todas para serem executadas em algum conceito de "recursos" (arbitrário, mas essas são entidades em seu aplicativo). O REST possui várias restrições que o tornam interessante (e particularmente bem associado ao HTTP).

Uma interface REST pode, mas não precisa, expor todas as operações CRUD em um recurso específico. O que está disponível em uma interface REST é arbitrário e pode mudar devido a permissões do sistema, considerações da interface do usuário e quão quente estava no dia em que a interface foi projetada e criada. Os dias mais quentes levam a interfaces mais minimalistas, geralmente, embora o oposto possa ser verdadeiro.


Obrigado Yar. Parece que "Tudo o que o CRUD faz e muito mais?" é um sim, com um detalhe técnico do REST se aplica a mais do que apenas entradas em um banco de dados.
Jesse Black #

@ Maudicus Atualizei a resposta, mas para ser específico: pode, mas não precisa.
Dan Rosenstark

Eu não diria que eles são necessários para que seu aplicativo seja considerado completo. Alguns aplicativos não precisam de inserções, remoções ou atualizações, por natureza.
Yam Marcovic

@Yam Marcovic, ok, ajustado
Dan Rosenstark

6

CRUD

  • CRUD são quatro tipos básicos de comandos SQL: Criar, Ler, Atualizar e Excluir
  • A maioria dos aplicativos possui algum tipo de funcionalidade CRUD
  • Um aplicativo CRUD é aquele que usa formulários para obter e entrar dados de um banco de dados

DESCANSAR

  • REST significa Representational State Transfer (às vezes é escrito "ReST")

  • Ele se baseia em um protocolo de comunicações armazenável em cache, sem estado e servidor-estado - e em praticamente todos os casos, o protocolo HTTP é usado

  • REST é um estilo de arquitetura para projetar aplicativos em rede


2

O REST é algo como uma página da Web para máquinas, na qual eles podem navegar, enquanto o CRUD é algo como SOAP, que está fortemente acoplado aos seus clientes. Essas são as principais diferenças. Ofc. eles são similares na superfície, mas o CRUD descreve a manipulação básica de entidades, enquanto o REST pode descrever a interface de qualquer aplicativo. Outra diferença é que o REST pode usar mais os 4 métodos HTTP. Seria uma resposta muito longa se eu quisesse coletar todas as diferenças. Se você verificar as perguntas sobre REST e SOAP, encontrará a maioria delas.

Eu acho que confundir REST com CRUD é um erro muito comum e a causa é que os desenvolvedores não têm tempo para ler sobre o REST em profundidade. Eles só querem usar a tecnologia - sem entendê-la - com base em exemplos limitados de estilo CRUD, escritos por desenvolvedores semelhantes. A grande maioria dos exemplos e tutoriais está refletindo uma grave falta de conhecimento. Mapear recursos REST para entidades e métodos HTTP para operações CRUD dessas entidades e usar REST sem hiperlinks é apenas um sintoma disso. Com o REST, você mapeia os hiperlinks (incluindo links com os métodos POST / PUT / DELETE / PATCH) para suas operações e identifica a operação no lado do cliente, verificando a relação de link (geralmente específica da API). Se um cliente REST não souber o que é uma relação de link e conhecer apenas os métodos HTTP e talvez alguns modelos de URI, esse não é um cliente REST, mas um cliente CRUD no HTTP. Outro erro comum de um cliente REST é um aplicativo javascript de página única em execução no navegador. É claro que você pode implementar esse cliente, mas o REST foi criado principalmente para clientes automáticos (aplicativos do lado do servidor criados por desenvolvedores que você nem conhece) e não para clientes manuais (aplicativos do navegador controlados pelo usuário criados por você). Ter apenas um cliente de navegador único pode ser um sinal de que você realmente não precisa do REST e acabou de administrar o projeto em excesso. Nesses casos, uma API CRUD é uma solução viável e os desenvolvedores estão chamando essas APIs CRUD como REST, porque não sabem a diferença. É claro que você pode implementar esse cliente, mas o REST foi criado principalmente para clientes automáticos (aplicativos do lado do servidor criados por desenvolvedores que você nem conhece) e não para clientes manuais (aplicativos do navegador controlados pelo usuário criados por você). Ter apenas um cliente de navegador único pode ser um sinal de que você realmente não precisa do REST e acabou de administrar o projeto em excesso. Nesses casos, uma API CRUD é uma solução viável e os desenvolvedores estão chamando essas APIs CRUD como REST, porque não sabem a diferença. É claro que você pode implementar esse cliente, mas o REST foi criado principalmente para clientes automáticos (aplicativos do lado do servidor criados por desenvolvedores que você nem conhece) e não para clientes manuais (aplicativos do navegador controlados pelo usuário criados por você). Ter apenas um cliente de navegador único pode ser um sinal de que você realmente não precisa do REST e acabou de administrar o projeto em excesso. Nesses casos, uma API CRUD é uma solução viável e os desenvolvedores estão chamando essas APIs CRUD como REST, porque não sabem a diferença.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.