Différence entre REST et CRUD
J'ai appris REST et ça 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 penser qu'ils sont similaires signifie que je ne les comprends pas.
Est-ce que REST est un "surensemble" de CRUD? Fait-il tout ce que fait CRUD 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 chacun gère.
CRUD signifie les opérations de base à effectuer dans un référentiel de données. Vous gérez directement des enregistrements ou des objets de données; en dehors de ces opérations, les enregistrements sont des entités passives. Il s'agit généralement de tables et d'enregistrements de base de données.
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 le commentaire d'un utilisateur. Cela signifie non seulement un enregistrement dans une table de "commentaires", mais aussi ses relations avec la ressource "utilisateur", le message auquel le 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, il peut avoir des effets secondaires importants, comme déclencher une alerte sur l'affiche originale, ou recalculer certains `` points '' de type jeu, ou mettre à jour certains `` flux de suiveurs ''.
De plus, une représentation des ressources inclut l'hypertexte (vérifiez le principe HATEOAS ), permettant au concepteur d'exprimer les relations entre les ressources ou guidant le REST client dans le workflow d'une opération.
En bref, 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 'live')) .
Le premier manipule les données de base, l'autre interagit avec un système complexe.
Tout d'abord, les deux ne sont que des initiales communes; ils n'ont rien à craindre.
Maintenant, CRUD est un terme simple qui a été abrégé car c'est une caractéristique courante dans de nombreuses applications, et 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 qui ont longtemps été inhérentes au protocole HTTP, mais rarement utilisées.
Lorsque vous avez une URL (Uniform Resource Locator) et que vous pointez votre navigateur vers la ligne d'adresse, vous envoyez un requête HTTP. Chaque demande HTTP contient des informations que le serveur peut utiliser pour savoir laquelle réponse HTTP renvoyer au client qui a émis la demande.
Chaque requête contient une URL, donc le serveur sait à quelle ressource vous souhaitez accéder, mais elle peut également contenir une méthode. Une méthode décrit ce que fait 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 émettent tout type de mises à jour (suppressions, insertions, mises à jour) via le POST.
Et à cause de cela, vous ne pouvez pas traiter une ressource (URL) comme une véritable ressource en soi. Vous deviez avoir des 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 qui sont plus intelligents car ils utilisent d'autres méthodes HTTP en dehors de POST, et programmez votre serveur pour pouvoir distinguer entre méthodes , pas seulement les URL. Ainsi, 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 message est une seule ressource. Avec REST vous traitez les ressources comme elles étaient censées être traitées. Vous dites au serveur quelle ressource vous souhaitez gérer et comment la gérer.
Il existe de nombreuses autres fonctionnalités de "l'architecture RESTful", que vous pouvez consulter sur Wikipedia, d'autres articles ou livres, si vous êtes intéressé. D'un autre côté, il n'y a pas grand-chose de plus à CRUD lui-même.
REST signifie "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 la théorie derrière REST consiste à exploiter les médias, l'hypermédia et un protocole sous-jacent pour gérer les informations sur un système distant.
CRUD, d'autre part, est un mnémonique pour les opérations courantes dont vous avez besoin pour les données dans une base de données: Créer Retrieve Update Delete. Mais ça ne va vraiment pas plus loin que ça.
C'est donc la réponse à votre question, mais je mentionnerai l'erreur courante que je vois lorsque REST et CRUD sont discutés ensemble. De nombreux développeurs souhaitent mapper REST sur CRUD directement, car REST sur HTTP prévoit 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", tandis que CRUD sépare créer et mettre à jour. Cela rend impossible (!) De faire un mappage général clair entre les deux (!)
GET et DELETE sont faciles ... GET === RETRIEVE et DELETE === DELETE.
Mais selon la spécification HTTP, PUT est en fait Créer ET Mettre à jour:
Utilisez PUT pour créer un nouvel objet lorsque vous savez tout sur lui, 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é quand aucun des autres verbes ne convient, car la spécification HTTP le définit comme le verbe "traitement des données"
Si votre équipe se bloque sur POST, n'oubliez pas que l'intégralité du WWW a été construit sur GET et POST;)
Donc, même s'il existe une similitude entre REST et CRUD, l'erreur que je vois la plupart des équipes est de faire une équivalence entre les deux. Une équipe doit vraiment faire attention lors de la définition d'une API REST pour ne pas trop se raccrocher à la mnémonique CRUD, car REST en tant que pratique a vraiment beaucoup de complexité supplémentaire qui ne fonctionne pas ' t mappez proprement au CRUD.
CRUD
- CRUD est 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 entrer et sortir des données d'une base de données
RESTE
REST signifie Representational State Transfer (il est parfois orthographié "ReST").
Il s'appuie sur un protocole de communication sans serveur, client-serveur, pouvant être mis en cache - et dans pratiquement tous les cas, le protocole HTTP est utilisé
REST est un style d'architecture pour la conception d'applications en réseau
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. Ces opérations 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, il pourrait s'agir d'un SGBD relationnel, mais aussi de fichiers YAML).
REST est un "style architectural" qui comprend généralement des opérations CRUD et d'autres opérations de niveau supérieur, toutes à effectuer sur un certain 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 couplé avec HTTP).
Une interface REST peut, mais ne doit pas, 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 des autorisations système, des considérations d'interface utilisateur et de la chaleur qu'il y avait le jour où l'interface a été conçue et créée. Les jours plus chauds conduisent généralement à des interfaces plus minimalistes, bien que l'inverse puisse être vrai.
REST est quelque chose comme une page Web pour les machines, qu'ils peuvent parcourir, tandis 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 des entités de base, tandis que REST peut décrire l'interface de n'importe quelle application. Une autre différence que REST peut utiliser plus le 4 méthodes HTTP. Ce serait une très longue réponse si je voulais collecter toutes les différences, si vous vérifiez les questions sur REST vs SOAP, alors vous en trouverez la plupart.
Je pense que confondre REST avec CRUD est une erreur très courante et la cause est que les développeurs n'ont pas le temps de lire en détail REST en profondeur. Ils ont juste veulent 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 didacticiels reflètent un grave manque de connaissances. Cartographie REST ressources aux entités et les méthodes HTTP aux opérations CRUD de ces entités et l'utilisation de REST sans hyperliens n'est qu'un symptôme de cela. Par REST vous mappez les hyperliens (y compris les liens avec POST/PUT/DELETE/PATCH) à 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) est, et ne connaît que les méthodes HTTP et peut-être certains modèles d'URI, alors ce n'est pas un client REST, mais un client CRUD sur HTTP. Une autre erreur courante qu'un REST client est une application javascript d'une seule page exécutée dans le navigateur. Bien sûr, vous pouvez implémenter un tel client, mais REST était principalement destiné aux clients automatiques (applications côté serveur écrites par des développeurs que vous ne connaissez même pas) et pas aux clients manuels (applications de navigateur contrôlées par l'utilisateur écrit 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 venez de suringénierie du projet. Dans ces cas, une API CRUD est une solution viable et les développeurs appellent ces API CRUD comme REST, car ils ne connaissent pas la différence.