API-Schnittstellen auf Basis von REST benötigt?

Sie suchen API-Schnittstellen auf Basis von REST für Ihre Projekte? Wir entwickeln API-Schnittstellen auf Basis von REST für Deutschland, Österreich und Schweiz. Gerne beraten wir Sie unverbindlich zum Thema API-Schnittstellen auf Basis von REST benötigt?

Jetzt API-Schnittstellen auf Basis von REST anfragen

Beratungsgespräch anfordern

Wir rufen Sie gerne zum Thema API-Schnittstellen auf Basis von REST zurück.

Was ist eine API auf Basis von REST?

REST ist die Abkürzung für REpresentational State Transfer. Es ist ein architektonischer Stil für verteilte Hypermediensysteme und wurde erstmals von Roy Fielding im Jahr 2000 in seiner berühmten Dissertation vorgestellt.

Wie jeder andere Architekturstil hat auch REST seine eigenen 6 Leitbedingungen, die erfüllt sein müssen, wenn eine Schnittstelle als RESTful bezeichnet werden soll. Diese Prinzipien sind unten aufgeführt.

Leitprinzipien von REST

  1. Client-Server - Indem wir die Probleme der Benutzeroberfläche von den Problemen des Datenspeichers trennen, verbessern wir die Portabilität der Benutzeroberfläche über mehrere Plattformen hinweg und verbessern die Skalierbarkeit durch Vereinfachung der Serverkomponenten.
  2. Zustandslos - Jede Anforderung von Client zu Server muss alle Informationen enthalten, die zum Verständnis der Anforderung erforderlich sind, und kann keinen auf dem Server gespeicherten Kontext nutzen. Der Sitzungsstatus bleibt daher vollständig auf dem Client.
  3. Cachefähig - Cache-Einschränkungen erfordern, dass die Daten in einer Antwort auf eine Anforderung implizit oder explizit als cachefähig oder nicht cachefähig gekennzeichnet werden. Wenn eine Antwort zwischengespeichert werden kann, erhält ein Client-Cache das Recht, diese Antwortdaten für spätere, gleichwertige Anforderungen wiederzuverwenden.
  4. Einheitliche Schnittstelle - Durch die Anwendung des Software-Engineering-Prinzips der Allgemeinheit auf die Komponentenschnittstelle wird die Gesamtsystemarchitektur vereinfacht und die Sichtbarkeit von Interaktionen verbessert. Um eine einheitliche Schnittstelle zu erhalten, sind mehrere architektonische Einschränkungen erforderlich, um das Verhalten von Komponenten zu steuern. REST wird durch vier Schnittstellenbeschränkungen definiert: Identifizierung von Ressourcen; Manipulation von Ressourcen durch Repräsentationen; selbstbeschreibende Botschaften; und Hypermedien als Motor des Anwendungszustands.
  5. Geschichtetes System - Durch den Stil "Geschichtetes System" kann eine Architektur aus hierarchischen Ebenen zusammengesetzt werden, indem das Verhalten der Komponenten so eingeschränkt wird, dass jede Komponente nicht über die unmittelbare Ebene hinaus "sehen" kann, mit der sie interagieren.
  6. Code on Demand (optional) - Mit REST kann die Clientfunktionalität erweitert werden, indem Code in Form von Applets oder Skripten heruntergeladen und ausgeführt wird. Dies vereinfacht Clients, indem die Anzahl der Features reduziert wird, die vor der Implementierung erforderlich sind.

Ressource

Die Schlüsselabstraktion von Informationen in REST ist eine Ressource. Jede Information, die benannt werden kann, kann eine Ressource sein: ein Dokument oder ein Bild, ein zeitlicher Dienst, eine Sammlung anderer Ressourcen, ein nicht virtuelles Objekt (z. B. eine Person) und so weiter. REST verwendet eine Ressourcen-ID, um die bestimmte Ressource zu identifizieren, die an einer Interaktion zwischen Komponenten beteiligt ist.

Der Status der Ressource zu einem bestimmten Zeitpunkt wird als Ressourcendarstellung bezeichnet. Eine Darstellung besteht aus Daten, Metadaten, die die Daten beschreiben, und Hypermedien-Links, die den Clients beim Übergang zum nächsten gewünschten Status helfen können.

Das Datenformat einer Darstellung wird als Medientyp bezeichnet. Der Medientyp gibt eine Spezifikation an, die definiert, wie eine Darstellung verarbeitet werden soll. Eine wirklich RESTful-API sieht aus wie Hypertext. Jede adressierbare Informationseinheit trägt eine Adresse, entweder explizit (z. B. Link- und ID-Attribute) oder implizit (z. B. abgeleitet von der Medientypdefinition und Repräsentationsstruktur).

Laut Roy Fielding:

Hypertext (oder Hypermedium) bedeutet die gleichzeitige Darstellung von Informationen und Steuerelementen, so dass die Informationen zu dem Vorteil werden, über den der Benutzer (oder Automat) Entscheidungen trifft und Aktionen auswählt. Denken Sie daran, dass Hypertext in einem Browser nicht HTML (oder XML oder JSON) sein muss. Maschinen können Verknüpfungen folgen, wenn sie das Datenformat und die Beziehungstypen verstehen.

Darüber hinaus müssen Ressourcendarstellungen selbsterklärend sein: Der Kunde muss nicht wissen, ob es sich bei einer Ressource um einen Mitarbeiter oder ein Gerät handelt. Es sollte auf der Grundlage des mit der Ressource verknüpften Medientyps handeln. In der Praxis werden Sie also am Ende viele benutzerdefinierte Medientypen erstellen - normalerweise einen Medientyp, der einer Ressource zugeordnet ist.

Jeder Medientyp definiert ein Standardverarbeitungsmodell. Beispielsweise definiert HTML einen Renderprozess für Hypertext und das Browserverhalten für jedes Element. Es hat keine Beziehung zu den Ressourcenmethoden GET / PUT / POST / DELETE /… außer der Tatsache, dass einige Medientypelemente ein Prozessmodell definieren, das wie folgt aussieht: „Ankerelemente mit einem href-Attribut erstellen einen Hypertext-Link, der bei Auswahl ruft eine Abrufanforderung (GET) für den URI auf, der dem CDATA-codierten href-Attribut entspricht. "

Ressourcenmethoden

Ein weiteres wichtiges Element im Zusammenhang mit REST sind Ressourcenmethoden, mit denen der gewünschte Übergang ausgeführt werden kann. Eine große Anzahl von Personen verknüpft Ressourcenmethoden fälschlicherweise mit HTTP-Methoden GET / PUT / POST / DELETE.

Roy Fielding hat noch nie eine Empfehlung gegeben, welche Methode unter welchen Bedingungen angewendet werden soll. Er betont lediglich, dass es sich um eine einheitliche Schnittstelle handeln sollte. Wenn Sie beschließen, dass HTTP POST zum Aktualisieren einer Ressource verwendet wird - anstatt dass die meisten Leute HTTP PUT empfehlen -, ist dies in Ordnung und die Anwendungsschnittstelle ist RESTful.