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?
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?
Respostas:
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.
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.
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.
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.
CRUD
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
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.