Definition

RESTful API

Bei einer RESTful API handelt es sich um eine Programmierschnittstelle (Application Programming Interface, API), die HTTP-Anfragen verwendet, um per GET, PUT, POST und DELETE auf Daten zuzugreifen.

Die REST-Technologie wird im Allgemeinen der robusteren SOAP-Technologie (Simple Object Access Protocol) vorgezogen, da REST weniger Bandbreite in Anspruch nimmt und somit besser für die

Internetnutzung geeignet ist. Eine API ist ein Code für eine Webseite, der es zwei Softwareprogrammen ermöglicht, miteinander zu kommunizieren. Sie beschreibt für den Entwickler, wie er das Programm schreiben muss, das Dienste von einem Betriebssystem oder einer anderen Anwendung anfordert.

Der von Browsern verwendete REST lässt sich als Sprache des Internets beschreiben. Mit der zunehmenden Nutzung der Cloud werden APIs immer mehr genutzt, um Webservices zugänglich zu machen. REST ist die logische Wahl für den Aufbau von APIs über die Nutzer sich mit Cloud-Diensten verbinden und mit ihnen interagieren können. Deshalb werden RESTful APIs von Websites wie Amazon, Google, LinkedIn und Twitter verwendet.

Wie RESTful-APIs funktionieren

RESTful API schlüsselt eine Transaktion in eine Reihe kleiner Module auf. Jedes von ihnen ist zuständig für einen bestimmten, die Transaktionen stützenden Teil. Diese Modularität bietet Entwicklern eine erhebliche Flexibilität, kann aber auch zur Herausforderung werden, da sie diese Eigenschaft von Anfang an berücksichtigen müssen. Zurzeit sind die Modelle Simple Storage Service (S3) von Amazon, OpenStack Swift und CDMI (Cloud Data Management Interface) am populärsten.

RESTful APIs machen sich die in RFC 2616 (Remote Function Call) definierten HTTP-Anfragemethoden zunutze. Sie verwenden PUT, um den Zustand einer Ressource (das kann ein Objekt, eine Datei oder ein Block sein) zu ändern oder sie zu aktualisieren. Mit GET wird eine Ressource abgerufen, mit POST wird sie erstellt und mit DELETE gelöscht.

Mit REST sind vernetzte Komponenten Ressourcen, zu denen Zugang beantragt werden muss. Es ist prinzipiell davon auszugehen, dass alle Aufrufe zustandslos sind; nichts kann vom RESTful-Dienst zwischen den Ausführungen zurückgehalten werden.

Da die Aufrufe zustandslos sind, ist REST nützlich in Cloud-Anwendungen. Zustandslose Komponenten können frei umverteilt werden, wenn es zu Ausfällen kommt, und sie können sich an Laständerungen anpassen. Das liegt daran, dass jede Anforderung an jede Instanz einer Komponente gerichtet werden kann; es kann nichts gespeichert werden, was bei der nächsten Transaktion erinnert werden muss. Das macht REST für die Webnutzung zum bevorzugten Modell, aber es ist auch bei Cloud-Diensten hilfreich, da hier die Anbindung an einen Service über die von der Dekodierung der URL abhängig gemacht wird. Beim Cloud Computing und bei Mikroservice gilt es daher als ausgemacht, dass das RESTful-API-Design in Zukunft der Regelfall sein wird.

RESTful API-Design und Architektur-Einschränkungen

Das RESTful API-Design wurde von Dr. Roy Fielding in seiner Doktorarbeit im Jahr 2000 definiert. Um eine echte RESTful-API zu sein, muss ein Webdienst die folgenden sechs REST-architektonischen Einschränkungen einhalten:

  • Verwendet eine einheitliche Benutzeroberfläche (UI). Ressourcen sollten durch eine einzige URL eindeutig identifizierbar sein, und nur durch die Verwendung der dem Netzwerkprotokoll zugrunde liegenden Methoden wie DELETE, PUT und GET mit HTTP sollte es möglich sein, eine Ressource zu manipulieren.
  • Basiert auf einem Client-Server. Es sollte eine klare Abgrenzung zwischen Client und Server bestehen. Die UI und das Sammeln von Anfragen sind die Aufgabe des Clienten. Datenzugriff, Workload-Management und Sicherheit sind die Aufgabe des Servers. Diese lose Kopplung von Client und Server macht es möglich, dass beide unabhängig voneinander entwickelt und verbessert werden können.
  • Operationen sind zustandslos. Alle Client-Server-Operationen sollten zustandslos sein, und jede erforderliche Zustandsverwaltung sollte auf dem Client und nicht auf dem Server stattfinden.
  • setzt RESTful-Ressource-Caching ein. Alle Ressourcen sollten Caching ermöglichen, es sei denn, es wird ausdrücklich angegeben, dass das Caching nicht möglich ist.
  • Verwendet ein geschichtetes System. REST ermöglicht eine Architektur, die aus mehreren Schichten von Servern besteht.
  • Code wird auf Anfrage ausgegeben. Meist sendet ein Server statische Darstellungen von Ressourcen in Form von XML (Extensible Markup Language) oder JSON (JavaScript Object Notation) zurück. Bei Bedarf können Server jedoch ausführbaren Code an den Client senden.

REST vs. SOAP

REST und SOAP (Simple Object Access Protocol) bieten verschiedene Methoden zum Aufrufen eines Webdienstes an. REST ist ein Architekturstil, während SOAP eine Spezifikation für das Standard-Kommunikationsprotokoll beim XML-basierten Nachrichtenaustausch definiert. REST-Anwendungen können SOAP verwenden.

REST-fähige Webdienste sind zustandslos. Eine REST-basierte Implementierung ist im Vergleich zu SOAP einfach, aber die Benutzer müssen den Kontext und den Inhalt verstehen, der weitergegeben wird, da es keine Standardregeln zur Beschreibung der REST-Webdienst-Schnittstelle gibt. REST-Dienste sind nützlich für Geräte mit eingeschränktem Profil, wie z.B. mobile Geräte, und lassen sich leicht in bestehende Websites integrieren.

SOAP erfordert weniger Installationscode als das Design von REST-Diensten. Die Web Services Description Language beschreibt einen gemeinsamen Satz von Regeln zur Definition der Nachrichten, Bindungen, Operationen und Standorte des Dienstes. SOAP-Webdienste werden für die asynchrone Verarbeitung und den asynchronen Aufruf verwendet.

Geschichte der RESTful-APIs

Vor REST verwendeten die Entwickler das Simple Object Access Protocol (SOAP) zur Integration von APIs. Um einen Aufruf zu tätigen, schrieben die Entwickler früher von Hand ein XML-Dokument mit einem Remote Procedure Call (RPC)-Aufruf im Body. Dann legten sie den Endpunkt fest und POSTeten ihren SOAP-Envelope an den Endpunkt.

Im Jahr 2000 beschlossen Roy Fielding und eine Gruppe von Entwicklern, einen Standard zu schaffen, damit jeder Server mit einem beliebigen anderen Server kommunizieren konnte. Er definierte REST und erläuterten architektonischen Einschränkungen in seiner bereits erwähnten Doktorarbeit von 2000 an der UC Irvine. Diese universellen Regeln erleichtern den Entwicklern die Integration von Software.

Salesforce war das erste Unternehmen, das im Jahr 2000 eine API als Teil seines Internet as a Service-Pakets verkaufte. Nur wenige Entwickler waren jedoch damals tatsächlich in der Lage, die komplizierte XML-API zu verwenden. Ebay baute eine REST-API auf, das den Markt des Unternehmens auf alle Websites ausweitete, die auf seine API zugreifen konnten. Dies erregte die Aufmerksamkeit von Amazon, das seine API im Jahr 2002 ankündigte.

Flickr wiederum startete im August 2004 seine eigene RESTful-API durch die Blogger Bilder auf ihren Websites und Social Media-Feeds einfach einbinden können. Facebook und Twitter veröffentlichten ihre APIs 2006. Allerdings geschah dies unter dem Druck von Entwicklern, die auf diesen Seiten Scraping betrieben hatten und Frankenstein-APIs erstellt hatten. Als Amazon Web Services (AWS) 2006 die Cloud mit auf den Weg brachte, konnten die Entwickler über die REST-API von AWS innerhalb von Minuten auf den Datenraum zugreifen, und alsbald eskalierte die Nachfrage nach öffentlichen APIs.

Seither nutzen Entwickler RESTful-API, um ihre Websites und Anwendungen um Funktionen zu erweitern. Heute gelten REST-API als das "Rückgrat des Internets".

Diese Definition wurde zuletzt im aktualisiert

Erfahren Sie mehr über Cloud Computing

- GOOGLE-ANZEIGEN

File Extensions and File Formats

Powered by:

ComputerWeekly.de

Close