Auf einen Blick: REST ist ein Architekturstil für APIs, der Ressourcen über HTTP verwaltet, während CRUD grundlegende Datenbankoperationen umfasst. REST-Prinzipien konzentrieren sich auf Zustandslosigkeit und einheitliche Schnittstellen und bieten ein robustes Framework für die Anwendungsentwicklung über die Datenbankbeschränkungen von CRUD hinaus.
- REST legt den Schwerpunkt auf Ressourcenrepräsentation und Hypermedia-Beziehungen.
- CRUD dreht sich in erster Linie um die Pflege von Datensätzen in Datenbanken.
Ein Teil der Verwirrung um REST und CRUD hängt mit der Überschneidung grundlegender Befehle zusammen, die von beiden Prozessen vorgeschrieben sind. Dies wird durch die Rails-Community verstärkt, die REST und seine GET, PUT, POST-Natur annimmt . Erfahrene Entwickler erkennen offensichtliche Ähnlichkeiten zwischen GET, PUT, POST und CREATE, READ, UPDATE, DELETE. Letztere Befehle bilden die Grundlage von CRUD. Und obwohl die Ähnlichkeiten nicht ignoriert werden können, sollte beachtet werden, dass REST nicht einfach eine Kopie von CRUD ist.
REST: Fundament & Prinzipien
Jeder REST-Befehl basiert auf einer Ressource. In REST ist eine Ressource eigentlich alles, worauf man über ein HTTP-Protokoll zeigen kann. Zum Beispiel ein Bild, eine Website, ein Dokument oder ein Wetterdienst. Die Möglichkeiten sind nahezu endlos. Einfach gesagt steht REST für Representational State Transfer, einen Architekturstil, der für verteilte Hypermedien oder eine Application Programming Interface entwickelt wurde. Letzteres wird wahrscheinlich als API bezeichnet. Eine andere Möglichkeit, eine API zu verstehen, ist, sie als Webservice zu definieren, der den architektonischen Prinzipien von REST entspricht. Jede API wird durch eine standardisierte HTTP-Anfragemethode aufgerufen: POST, GET, PUT und seltener DELETE. DELETE wird meist impliziert, aber nicht unbedingt ausgesprochen. Die Begriffe, die REST-Prinzipien definieren, wurden in Dr. Roy Fieldings' Dissertation "Architectural Styles and the Design of Network-Based Software Infrastructure" eingeführt. Insgesamt kann REST als Standard in der Entwicklung von Serviceanwendungen betrachtet werden. Es bietet eine Alternative zu:
- Einfaches Objektzugriffsprotokoll (SOAP)
- Common Object Request Broker Architektur (CORBA)
- RMI
- Viele andere
Prinzipien von REST
Es gibt sechs leitende Einschränkungen von REST:
- Client-Server-Mandat
- Staatenlosigkeit
- Cache
- Schnittstelle/einheitlicher Vertrag
- Geschichtetes System
- Code-on-Demand (optional)
Schauen wir uns jeden an.
Client-Server-Mandat
Diese Verpflichtung unterstreicht, dass REST ein verteilter Ansatz ist, der durch die Trennung zwischen Client und Server besteht. Jeder Dienst verfügt über mehrere Fähigkeiten und hört Anfragen an. Anfragen werden vom Konsumenten gestellt und vom Server akzeptiert oder abgelehnt.
Staatenlosigkeit
Aufgrund der Natur der Zustandslosigkeit ist sie ein Leitprinzip der RESTful-Architektur. Sie legt fest, welche Art von Befehlen zwischen Client und Server angeboten werden dürfen. Die Implementierung zustandsloser Anfragen bedeutet, dass die Kommunikation zwischen Konsument und Dienst durch die Anfrage initiiert wird, und die Anfrage enthält alle Informationen, die der Server zur Antwort benötigt.
Cache
Cache verlangt, dass Serverantworten entweder als cachebar oder nicht gekennzeichnet sind. Caching hilft, einige der Einschränkungen der Zustandslosigkeit zu mildern. Zum Beispiel eine Anfrage, die vom Konsumenten zwischengespeichert wird, um zu vermeiden, dieselbe Anfrage zweimal erneut einzureichen.
Schnittstelle/einheitlicher Vertrag
Die RESTful-Architektur folgt den Prinzipien, die einen Uniform Contract definieren. Dies verbietet die Verwendung mehrerer eigenständiger Schnittstellen innerhalb einer API. Stattdessen wird eine Schnittstelle über Hypermedia-Verbindungen verteilt.
Geschichtetes System
Dieses Prinzip macht die RESTful-Architektur so skalierbar. In einem Layered System werden mehrere Schichten verwendet, um die Schnittstelle zu erweitern und zu erweitern. Keine der Schichten kann in die andere hineinsehen. Dadurch können neue Befehle und Middleware hinzugefügt werden, ohne die ursprünglichen Befehle und die Funktion zwischen Client und Server zu beeinträchtigen.
Optional: Code-on-demand
RESTful-Anwendungen müssen Code-On-Demand nicht enthalten, aber sie müssen über Client-Server-, Statelessness, Caching, Uniform Contract und Layered Systems verfügen. Code-on-Demand ermöglicht es, die Logik innerhalb der Clients von der innerhalb der Server zu trennen. Dadurch können sie unabhängig von der Serverlogik aktualisiert werden.
REST in einer Nussschale
REST bezeichnet eine Reihe definierender Prinzipien für die Entwicklung von APIs. Es verwendet HTTP-Protokolle wie GET, PUT, POST, um Ressourcen mit Aktionen innerhalb einer Client-Server-Beziehung zu verknüpfen. Zusätzlich zum Client-Server-Mandat gibt es mehrere weitere definierende Einschränkungen. Die Prinzipien der RESTful-Architektur dienen dazu, eine stabile und zuverlässige Anwendung zu schaffen, die Einfachheit und Endbenutzerzufriedenheit bietet.
CRUD: Grundlage & Prinzipien
Mit einem besseren Verständnis der RESTful-Architektur ist es Zeit, sich mit CRUD zu beschäftigen. CRUD ist ein Akronym für:
- CREATE
- LESEN
- AKTUALISIERUNG
- LÖSCHEN
Diese bilden die Standard-Datenbankbefehle, die die Grundlage von CRUD bilden. Viele Softwareentwickler betrachten diese Befehle bestenfalls als primitive Orientierung. Das liegt daran, dass CRUD nicht als moderne Methode zur API-Erstellung entwickelt wurde. Tatsächlich liegen die Ursprünge von CRUD in Datenbankeinträgen. Per Definition ist CRUD eher ein Zyklus als ein Architektursystem. Auf jeder dynamischen Website gibt es wahrscheinlich mehrere CRUD-Zyklen. Zum Beispiel kann ein Käufer auf einer E-Commerce-Seite ein Konto ERSTELLEN, Kontoinformationen AKTUALISIEREN und Dinge aus einem Einkaufswagen LÖSCHEN. Ein Warehouse Operations Manager, der dieselbe Seite nutzt, kann Versandunterlagen erstellen, bei Bedarf ABRUFEN und Lieferlisten AKTUALISIEREN. Abrufen wird im CRUD-Zyklus manchmal durch LESEN ersetzt.
Datenbank-Ursprünge
Der CRUD-Zyklus ist als Methode von Funktionen zur Verbesserung persistenter Speicher konzipiert – zum Beispiel mit einer Datenbank von Datensätzen. Wie der Name schon sagt, überdauert persistente Speicherung die Prozesse, die ihn erstellt haben. Diese Funktionen verkörpern alle Merkmale einer relationalen Datenbankanwendung. In der modernen Softwareentwicklung hat CRUD seine Ursprünge als grundlegende Funktionen einer Datenbank überschritten und passt sich nun an Designprinzipien für dynamische Anwendungen wie HTTP-Protokolle, DDS und SQL an.
Prinzipien von CRUD
Wie oben erwähnt, sind die Prinzipien des CRUD-Zyklus definiert als ERSTELLEN, LESEN/ABRUFEN, AKTUALISIEREN und LÖSCHEN:
- CREATE-Prozeduren generieren neue Datensätze über INSERT-Anweisungen.
- READ-Prozeduren lesen die Daten basierend auf Eingabeparametern. Ähnlich erfassen RETRIEVE-Prozeduren Datensätze basierend auf Eingabeparametern.
- UPDATE-Prozeduren ändern Datensätze, ohne sie zu überschreiben.
- DELETE-Prozeduren löschen, wo es angegeben ist.
REST & CRUD-Ähnlichkeiten
Wenn man sich die beiden oben beschriebenen ansieht, kann es schwer zu verstehen sein, warum sie oft auf die gleiche Weise behandelt werden:
- REST ist eine robuste API-Architektur.
- CRUD ist ein Kreislauf zur Aktualisierung und dauerhafter Aufzeichnungen.
Der Mangel an Klarheit zwischen beiden geht für viele verloren, wenn sie nicht bestimmen, wann CRUD endet und REST beginnt. Wir haben oben erwähnt, dass CRUD auf DDS-, SQL- und HTTP-Protokolle abgebildet werden kann. Und dass HTTP-Protokolle die Verbindung zwischen Ressourcen in der RESTful-Architektur sind, einem Kernstück der REST-Basis. Die Abbildung von CRUD-Prinzipien auf REST bedeutet, zu verstehen, dass GET, PUT, POST und CREATE, READ, UPDATE, DELETE auffallende Ähnlichkeiten haben, weil die erste Gruppe die Prinzipien der letzteren anwendet. Es ist jedoch auch wichtig zu beachten, dass eine RESTful-Softwarearchitektur mehr bedeutet als nur das Mapping von GET, PUT, POST-Befehlen.
REST vs. CRUD: Was ist der Unterschied?
CRUD ist ein Zyklus, der von Natur aus auf REST abgebildet werden kann. Permanenz, wie sie im Kontext von CRUD definiert ist, ist eine intelligente Möglichkeit für Anwendungen, operative Befehle zwischen Clients und Diensten zu mindern. Aber REST steuert weit mehr als nur die Permanenz innerhalb seiner Architekturprinzipien. Hier sind einige der Wege, auf denen REST sich nicht nur von CRUD unterscheidet, sondern auch viel mehr bietet:
- REST ist ein architektonisches System, das auf Ressourcen und Hypermedia basiert, über HTTP-Protokolle
- CRUD ist ein Zyklus, der zur Pflege permanenter Datensätze in einer Datenbankumgebung gedacht ist
- CRUD-Prinzipien werden REST-Befehlen zugeordnet, um den Zielen der RESTful-Architektur zu entsprechen
In RUHE:
- Die Darstellungen müssen hinsichtlich der Ressourcen einheitlich sein
- Hypermedia stellt Beziehungen zwischen Ressourcen dar
- Nur ein Eintrag in eine API, um eine eigenständige Schnittstelle zu erstellen, dann ein Hyperlink, um Beziehungen zu erstellen
Der Weg nach vorne
Wenig überraschend ist die Nachfrage nach RESTful-Architektur im Laufe der Jahre weiter gestiegen. Und da es zu einem noch beliebteren Architekturstil wird, sollten Entwickler in der Lage sein, zwischen den Prinzipien anderer Optionen wie SOAP, CORBA und RMI zu unterscheiden.
Zusätzliche Ressourcen
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.