Diferença entre REST e CRUD

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

CRUD significa as operações básicas a serem feitas em um repositório de dados. Você manipula diretamente 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 um URL. Normalmente, esses não são objetos de dados, mas abstrações complexas de objetos.

Por exemplo, um recurso pode ser um comentário do usuário. Isso significa não apenas um registro em uma tabela de "comentários", mas também suas relações com o recurso "usuário", a postagem à qual o comentário está anexado, talvez outro comentário ao qual ele responde.

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

Além disso, uma representação de recursos inclui hipertexto (verifique o princípio HATEOAS ), permitindo que o designer expresse relações entre recursos, ou orientar o cliente REST no fluxo de trabalho de uma operação.

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

Em primeiro lugar, ambos são apenas iniciais comuns; eles não são nada para se ter medo.

Agora, o CRUD é um termo simples que foi abreviado porque é um recurso comum em muitos aplicativos e é mais fácil dizer CRUD . Ele descreve as 4 operações básicas que você pode executar em dados (ou em um recurso). Criar, ler, atualizar, excluir.

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

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

Cada solicitação contém uma URL, então o servidor sabe qual recurso 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 foi usado com muita frequência.

Normalmente, as pessoas apenas criam links para páginas através do método GET e emitem qualquer tipo de atualizações (exclusões, inserções, atualizações) por meio do método POST.

E por causa disso você não poderia tratar um recurso (URL) como um verdadeiro recurso em si. 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 que são mais inteligentes porque eles usam outros métodos HTTP além do POST e programam seu servidor para 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 de que um único URL descreve um único recurso. Um único post é um recurso único. Com o REST, você trata os recursos da maneira como eles deveriam ser tratados. Você está dizendo ao servidor qual recurso você quer manipular e como lidar com isso.

Existem muitos outros recursos para "Arquitetura RESTful", sobre os quais você pode ler na Wikipédia, em outros artigos ou livros, se estiver interessado. Não há muito mais para o próprio CRUD, por outro lado.

REST significa "transferência de estado representacional", o que significa que é tudo sobre a comunicação e modificação do estado de algum recurso em um sistema.

O REST se envolve bastante, porque a teoria por trás do REST adota 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 dados em um banco de dados: Criar Recuperar Excluir Atualização. Mas realmente não é mais profundo que isso.

Então essa é a resposta para sua pergunta, mas vou mencionar o erro comum que vejo quando REST e CRUD são discutidos juntos. Muitos desenvolvedores desejam mapear o REST para o CRUD diretamente, porque o REST over HTTP fornece GET PUT POST e DELETE, enquanto o CRUD fornece CREATE RETRIEVE UPDATE DELETE. É natural querer mapear os verbos REST diretamente para as 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 limpo entre os dois (!)

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

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

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

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

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

• Use POST para acrescentar um novo objeto a uma coleção - isto é, criar um novo objeto

• O POST também é usado quando nenhum dos outros verbos é adequado, já que a especificação HTTP o define como o verbo "processamento de dados"

• Se a sua equipe está ficando travada no POST, lembre-se de que toda a WWW foi construída em GET e 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 presa no mnemônico CRUD, porque o REST como uma prática realmente tem muita complexidade adicional que não mapeia de forma limpa para o CRUD.

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, essas 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 um arquivo YAML).

REST é um "estilo de arquitetura" que normalmente inclui operações CRUD e outras operações de nível superior, todas a serem executadas em algum conceito de "recursos" (arbitrário, mas são entidades em sua aplicação). REST tem um monte de restrições que o tornam interessante (e particularmente bem pareado com 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 ser alterado devido a permissões do sistema, considerações sobre a interface do usuário e quão quente ficou no dia em que a interface foi projetada e criada. Os dias mais quentes levam a interfaces mais minimalistas, geralmente, embora o contrário possa ser verdadeiro.

CRUD

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

REST

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

• Ele conta com um protocolo de comunicações que pode ser armazenado em estado, servidor-cliente e armazenável em cache - e, em praticamente todos os casos, o protocolo HTTP é usado

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

O REST é algo como uma página da Web para máquinas, que eles podem navegar, enquanto o CRUD é algo como o SOAP, que é strongmente acoplado a seus clientes. Estas são as principais diferenças. Ofc. eles são semelhantes 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 questões sobre REST vs SOAP, então você encontrará a maioria delas.

Eu acho confuso 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 de estilo CRUD limitados escritos por desenvolvedores similares. A grande maioria dos exemplos e tutoriais está refletindo uma séria falta de conhecimento. O mapeamento de recursos REST para entidades e métodos HTTP para operações CRUD dessas entidades e o uso de REST sem hiperlinks é apenas um sintoma disso. Por REST você mapeia hyperlinks (incluindo links com 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, isso não é um cliente REST, mas um cliente CRUD em HTTP. Outro erro comum que um cliente REST é um aplicativo javascript de página única em execução no navegador. É claro que você pode implementar tal cliente, mas o REST foi criado principalmente para clientes automáticos (aplicativos do lado do servidor escritos por desenvolvedores que você nem conhece) e não para clientes manuais (aplicativos de navegador controlados pelo usuário escritos por você). Ter apenas um único cliente de navegador pode ser um sinal de que você realmente não precisa do REST e apenas superestimou o projeto. 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.