Différence entre REST et CRUD

J'ai appris à rester et cela ressemble beaucoup à CRUD (d'après ce que j'ai lu sur CRUD).

Je sais qu'ils sont différents, et je me demande si, s'ils sont similaires, cela signifie que je ne les comprends pas.

Est-ce que REST est un "super ensemble" de CRUD? Est-ce que tout CRUD fait et plus?

Étonnamment, je ne vois pas dans les autres réponses ce que je considère comme la vraie différence entre REST et CRUD: ce que chacune gère.

CRUD désigne les opérations de base à effectuer dans un référentiel de données. Vous manipulez directement des enregistrements ou des objets de données; En dehors de ces opérations, les enregistrements sont des entités passives. En règle générale, il ne s'agit que de tables de base de données et d'enregistrements.

REST, quant à lui, fonctionne sur des représentations de ressources, chacune identifiée par une URL. Ce ne sont généralement pas des objets de données, mais des abstractions d'objets complexes.

Par exemple, une ressource peut être un commentaire d'utilisateur. Cela signifie non seulement un enregistrement dans une table 'commentaire', mais également ses relations avec la ressource 'utilisateur', le message auquel ce commentaire est attaché, peut-être un autre commentaire auquel il répond.

Opérer sur le commentaire n'est pas une opération de base de données primitive, elle peut avoir des effets secondaires importants, tels que le déclenchement d'une alerte sur l'affiche d'origine, le recalcul de «points» du jeu ou la mise à jour d'un «flux d'abonnés».

De plus, une représentation de ressource inclut un hypertexte (vérifiez le principe HATEOAS ), permettant au concepteur d'exprimer des relations entre les ressources ou guidant le client REST dans le flux de travail d'une opération.

En résumé, CRUD est un ensemble d'opérations primitives (principalement pour les bases de données et les stockages de données statiques), tandis que REST est un style d'API de très haut niveau (principalement pour les services Web et autres systèmes "actifs").

Le premier manipule des données de base, le second interagit avec un système complexe.

Tout d'abord, les deux sont simplement des initiales communes; ils n'ont rien à craindre.

CRUD est un terme simple qui a été abrégé parce qu’il est une caractéristique commune à de nombreuses applications et qu’il est plus facile de dire CRUD . Il décrit les 4 opérations de base que vous pouvez effectuer sur des données (ou une ressource). Créer, lire, mettre à jour, supprimer.

Cependant, REST est une pratique nommée (tout comme AJAX), pas une technologie en soi. Il encourage l'utilisation de fonctionnalités inhérentes au protocole HTTP, mais rarement utilisées.

Lorsque vous avez une URL (Uniform Resource Locator ) et que vous la dirigez par la ligne d'adresse, vous envoyez une requête HTTP . Chaque demande HTTP contient des informations que le serveur peut utiliser pour savoir quelle réponse HTTP envoyer au client qui a émis la demande.

Chaque demande contient une URL, afin que le serveur sache à quelle ressource vous souhaitez accéder, mais il peut également contenir une méthode . Une méthode décrit quoi faire avec cette ressource.

Mais ce concept de "méthode" n'a pas été utilisé très souvent.

Habituellement, les gens lient simplement des pages via la méthode GET et publient tout type de mises à jour (suppressions, insertions, mises à jour) via la méthode POST.

Et à cause de cela, vous ne pouviez pas traiter une ressource (URL) comme une vraie ressource en soi. Vous devez disposer d'URL distinctes pour la suppression, l'insertion ou la mise à jour de la même ressource. Par exemple:

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

Avec REST, vous créez des formulaires plus intelligents, car ils utilisent d'autres méthodes HTTP que POST, et programmez votre serveur pour qu'il puisse faire la distinction entre les méthodes , pas seulement les URL. Donc par exemple:

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

N'oubliez pas qu'une seule URL décrit une seule ressource. Un seul poste est une seule ressource. Avec REST, vous traitez les ressources comme elles étaient censées être traitées. Vous indiquez au serveur quelle ressource vous souhaitez gérer et comment le gérer.

Il existe de nombreuses autres fonctionnalités dans "l'architecture RESTful", que vous pouvez lire dans Wikipedia, dans d'autres articles ou dans des livres, si cela vous intéresse. Il n'y a pas beaucoup plus à CRUD lui-même, d'autre part.

REST signifie "representational state transfer" (transfert d'état représentatif), ce qui signifie qu'il s'agit de communiquer et de modifier l'état d'une ressource dans un système.

REST est très impliqué, car sa théorie consiste à exploiter les médias, l'hypermédia et un protocole sous-jacent pour gérer les informations sur un système distant.

CRUD, quant à lui, est un mnémonique des opérations courantes nécessaires pour les données d'une base de données: Créer Récupérer Mettre à jour Supprimer. Mais cela ne va pas vraiment plus loin que cela.

Voilà donc la réponse à votre question, mais je mentionnerai l'erreur commune que je vois quand REST et CRUD sont discutés ensemble. Un grand nombre de développeurs souhaitent mapper directement REST sur CRUD, car REST over HTTP fournit GET PUT POST et DELETE, tandis que CRUD fournit CREATE RETRIEVE UPDATE DELETE. Il est naturel de vouloir mapper les verbes REST directement aux opérations CRUD.

Cependant, HTTP utilise un style "créer ou mettre à jour", alors que CRUD sépare créer et mettre à jour. Cela rend impossible (!) L’établissement d’une correspondance nette et générale entre les deux (!)

GET et DELETE sont faciles ... GET === RETRIEVE, and DELETE === DELETE.

Mais selon les spécifications HTTP, PUT est en réalité Créer et mettre à jour:

• Utilisez PUT pour créer un nouvel objet lorsque vous savez tout sur celui-ci, y compris son identifiant.

• Utilisez PUT pour mettre à jour un objet (généralement avec une représentation complète de l'objet)

POST est le verbe "traitement" et est considéré comme le verbe "ajouter":

• Utilisez POST pour ajouter un nouvel objet à une collection, c'est-à-dire créer un nouvel objet.

• POST est également utilisé lorsqu'aucun des autres verbes ne convient parfaitement, car la spécification HTTP le définit comme le verbe "traitement de données".

• Si votre équipe s’accroche à POST, rappelez-vous que l’ensemble du WWW a été construit sur GET et POST;)

Ainsi, bien qu'il y ait une similitude entre REST et CRUD, l'erreur que la plupart des équipes commettent est de faire une équivalence entre les deux. Une équipe doit vraiment être prudente lors de la définition d’une API REST afin de ne pas trop s’accrocher à la mnémonique de CRUD, car REST, en tant que pratique, a beaucoup de complexité supplémentaire qui n’apparaît pas clairement à CRUD.

CRUD spécifie un ensemble minimal de verbes de stockage de base pour la lecture et l'écriture de données: créer, lire, mettre à jour et supprimer. Ensuite, vous pouvez créer d'autres opérations en les agrégeant. Celles-ci sont généralement considérées comme des opérations de base de données, mais ce qui est considéré comme une base de données est arbitraire (par exemple, pourrait être un SGBD relationnel, mais pourrait également être un fichier YAML).

REST est un "style architectural" qui comprend généralement des opérations CRUD et d'autres opérations de niveau supérieur, qui doivent toutes être exécutées sur un concept de "ressources" (arbitraire, mais ce sont des entités dans votre application). REST a un tas de contraintes qui le rendent intéressant (et particulièrement bien associé à HTTP).

Une interface REST peut, mais n'est pas obligée, exposer toutes les opérations CRUD sur une ressource particulière. Ce qui est disponible dans une interface REST est arbitraire et peut changer en raison d'autorisations système, de considérations relatives à l'interface utilisateur et de la température à laquelle il faisait chaud le jour où l'interface a été conçue et créée. Les journées les plus chaudes conduisent à des interfaces plus minimalistes, généralement, bien que le contraire puisse être vrai.

CRUD

• CRUD est composé de quatre types de base de commandes SQL: Créer, Lire, Mettre à jour et Supprimer.
• La plupart des applications ont une sorte de fonctionnalité CRUD
• Une application CRUD est une application qui utilise des formulaires pour insérer des données dans une base de données.

DU REPOS

• REST signifie "Representational State Transfer" (il est parfois orthographié "ReST").

• Il repose sur un protocole de communication sans état, client-serveur et pouvant être mis en cache - et dans presque tous les cas, le protocole HTTP est utilisé

• REST est un style d'architecture pour la conception d'applications en réseau.

REST est quelque chose qui ressemble à une page Web pour les machines, qu'ils peuvent parcourir, alors que CRUD est quelque chose comme SOAP, qui est fortement couplé à ses clients. Ce sont les principales différences. Ofc. ils sont similaires en surface, mais CRUD décrit la manipulation de base des entités, tandis que REST peut décrire l'interface de n'importe quelle application. Autre différence, REST peut utiliser davantage les 4 méthodes HTTP. Ce serait une très longue réponse si je voulais rassembler toutes les différences, si vous vérifiiez les questions concernant REST vs SOAP, vous en découvririez la plupart.

Je pense que confondre REST avec CRUD est une erreur très courante et la raison en est que les développeurs n’ont pas le temps d’approfondir leurs connaissances sur REST. Ils veulent juste utiliser la technologie - sans la comprendre - sur la base d’exemples limités de style CRUD écrits par des développeurs similaires. La grande majorité des exemples et des tutoriels reflètent un grave manque de connaissances. La correspondance des ressources REST avec les entités et des méthodes HTTP avec les opérations CRUD de ces entités et l'utilisation de REST sans hyperlien n'en sont que le symptôme. Par REST, vous mappez des hyperliens (y compris des liens avec des méthodes POST / PUT / DELETE / PATCH) vers vos opérations et vous identifiez l’opération côté client en vérifiant la relation de lien (généralement spécifique à l’API). Si un client REST ne sait pas ce qu'est une relation de lien et ne connaît que les méthodes HTTP et peut-être certains modèles d'URI, il ne s'agit alors pas d'un client REST, mais d'un client CRUD sur HTTP. Une autre erreur courante selon laquelle un client REST est une application javascript d'une seule page s'exécutant dans le navigateur. Bien sûr, vous pouvez implémenter un tel client, mais REST était destiné principalement aux clients automatiques (applications côté serveur écrites par des développeurs que vous ne connaissez même pas) et non aux clients manuels (applications de navigateur contrôlées par l'utilisateur écrites par vous). Le fait de n'avoir qu'un seul client de navigateur peut être un signe que vous n'avez pas vraiment besoin de REST et que vous avez simplement trop modifié le projet. Dans ces cas, une API CRUD est une solution viable et les développeurs appellent ces API CRUD comme étant REST, car ils ne connaissent pas la différence. Bien sûr, vous pouvez implémenter un tel client, mais REST était destiné principalement aux clients automatiques (applications côté serveur écrites par des développeurs que vous ne connaissez même pas) et non aux clients manuels (applications de navigateur contrôlées par l'utilisateur écrites par vous). Le fait de n'avoir qu'un seul client de navigateur peut être un signe que vous n'avez pas vraiment besoin de REST et que vous avez simplement trop modifié le projet. Dans ces cas, une API CRUD est une solution viable et les développeurs appellent ces API CRUD comme étant REST, car ils ne connaissent pas la différence. Bien sûr, vous pouvez implémenter un tel client, mais REST était destiné principalement aux clients automatiques (applications côté serveur écrites par des développeurs que vous ne connaissez même pas) et non aux clients manuels (applications de navigateur contrôlées par l'utilisateur écrites par vous). Le fait de n'avoir qu'un seul client de navigateur peut être un signe que vous n'avez pas vraiment besoin de REST et que vous avez simplement trop modifié le projet. Dans ces cas, une API CRUD est une solution viable et les développeurs appellent ces API CRUD comme étant REST, car ils ne connaissent pas la différence.