Bevor wir konkret auf die REST Schnittstelle, auch Application Programming Interface oder kurz API genannt, eingehen, hier ein beispielhafter Erkl\u00e4rungsversuch, wieso solche Schnittstellen so praktisch sind: Da Schnittstellen nach dem Prinzip von „Plug and Play“ funktionieren, eignet sich hier der Vergleich mit dem Stromanschluss recht gut. Stellen Sie sich vor, Sie m\u00fcssten, bevor Sie eine Tasse Kaffe machen k\u00f6nnen, sich zuerst mit der ganzen Elektrotechnik auseinandersetzen, um fliessenden Strom vom Energiehersteller zu Ihnen nach Hause kriegen zu k\u00f6nnen.<\/p>\n\n\n\n
Es ist offensichtlich, dass dies aus diversen Gr\u00fcnden nicht wirklich Sinn ergeben w\u00fcrde. Das m\u00f6glicherweise fehlende Know-How und die sehr wahrscheinliche Ineffizienz im Prozess sind zwei naheliegende Begr\u00fcndungen. Stattdessen schliessen Sie doch einfach die Kaffeemaschine an der Steckdose an und los geht’s. So ziemlich identisch sind Schnittstellen zu verstehen. Sprich, Sie erhalten somit den fixfertigen Zugang zu einer Funktionalit\u00e4t, die Sie f\u00fcr irgendetwas gebrauchen k\u00f6nnen und nicht etwas zuerst selbst noch bauen m\u00fcssen.<\/p>\n\n\n\n
Schnittstellen sind also eine sehr praktische Art eines codebasierten Konstruktes, die uns erlauben, Systeme und Funktionalit\u00e4ten einfacher und wesentlich schneller zu bauen. Sie reduzieren die Komplexit\u00e4t des Source Codes und stellen uns eine einfach anwendbare Syntax zur Ansteuerung eines Programms zur Verf\u00fcgung, wodurch wir die Kommunikation zwischen zwei unabh\u00e4ngigen Softwarekomponenten herstellen k\u00f6nnen.<\/p>\n\n\n\n
Basierend auf der Art wie Systeme und Software miteinander interagieren und die Applikationsarchitektur bilden, gibt es verschiedene Schnittstellen f\u00fcr Hardware, Betriebssysteme, Datenstrukturen, Web Services, etc. Handelt es sich um softwarespezifische Schnittstellen, sind diese oftmals nur \u00fcber spezielle Programmiersprachen implementierbar. Zudem haben sie nicht selten eine eigene Syntax und Funktionen, was f\u00fcrs effiziente Handling entweder spezifische Kompetenzen oder Kapazit\u00e4t zum Einlesen voraussetzt. Dann gibts auch noch dateibasierte Schnittstellen, die Dateien in bestimmten Formaten austauschen, wodurch ein System aber langsam und fehleranf\u00e4llig wird. Wenns um webbasierte Schnittstellen geht, spricht man in der Regel je nach Datantransferformat im Request-Respond Messaging von SOAP (Simple Object Access Protocol<\/a>), RPC (Remote Procedure Call<\/a>) oder eben von der REST API. Letztere ist eine der bekannteren. Und diese schauen wir uns jetzt nachstehend genauer an. <\/p>\n\n\n\n Die REST (Representational State Transfer) API ist eine der wohl simpelsten Architekturen, wie Schnittstellen designt werden k\u00f6nnen. Sie hat zum Ziel die Verbindung zweier Webapplikationen durch die Standardisierung der Modalit\u00e4t radikal zu vereinfachen. Representational State Transfer heisst sie, da in der Kommunikation zwischen den Applikationen Informationen \u00fcber den Zustand der Server-Ressourcen in beispielsweise JSON-, XML- oder HTML-Format geteilt beziehungsweise repr\u00e4sentiert werden. Dabei erlaubt die REST API einem Client, also zum Beispiel Ihnen, Aktionen wie Ressourcen zu lesen (GET), neue Objekte zu erstellen (POST), Informationen zu aktualisieren\/editieren (PUT) oder diese zu l\u00f6schen (DELETE). Die entsprechenden Befehle schickt der Client einfach \u00fcber HTTP<\/a>. Neben dieser einheitlichen Schnittstelle gibt es noch weitere Restriktionen, welche eingehalten werden m\u00fcssen, um auch wirklich dem REST-Format zu entsprechen (Client und Server Separation, stateless<\/a>, geschichtetes System<\/a> und cacheable<\/a>). Diese behandeln wir hier aber nicht weiter.<\/p>\n\n\n\n Wieso wir uns nun bei Parashift daf\u00fcr entschieden haben, eine REST API f\u00fcr die Integration unserer Produktes zu entwickeln, hat einerseits mit den allgemeinen Vorteilen von REST APIs zu tun:<\/p>\n\n\n\nDie REST API<\/h4>\n\n\n\n
Vorteile<\/h4>\n\n\n\n
\n