Diese Seite arbeitet am besten mit mindestens Version 8 von Internet Explorer.
 
19.11.2017English
  • Startseite
  • Produkte
  • Leistungen
  • Support
  • Aktuelles
  • Denapp
  • Kunden
  • Produkte
  • Denapp Bankdata Service
  • Bestellen
  • Beschreibung
  • Preisliste
  • Dokumentation
  • Bankdata Client C# (.NET 2.0) Beispielprojekt
  • Leistungen
  • Softwareentwicklung
  • Web-Lösungen
  • Support
  • Online Bankdaten
  • Bankverbindung in SEPA konvertieren
  • IBAN berechnen
  • SEPA Bankverbindung prüfen
  • IBAN prüfen
  • Deutsche Bankverbindung prüfen
  • Bankdaten suchen
  • Online MEdi
  • Kostenträgerverzeichnis durchsuchen
  • Hilfsmittelverzeichnis durchsuchen
  • Tools
  • Denapp HtmlShrink
  • Denapp CssImageInclude
  • Suche
  • Aktuelles
  • Denapp
  • Denapp Bankdata Service
  • Denapp
  • Kontakt
  • Nutzungsbedingungen
  • Datenschutz
  • AGB
  • AGB
  • Bankdata Service BGB
  • Impressum
  • REST - Representational State Transfer

    Allgemeines

    Thomas Roy Fielding beschrieb in einer Dissertation eine Architektur, die er REpresentational State Transfer Architektur oder kurz REST nannte. Fielding postulierte dabei allgemeine Regeln, die in der größten verteilten Anwendung überhaupt, dem World Wide Web, erfolgreich eingesetzt werden. Viele Suchmaschinen, Buchungssysteme und Shops sind, ohne dass dies bei der Entwicklung geplant worden wäre, bereits als REST basierte Webdienste verfügbar. REpresentational State Transfer beschreibt eine Architektur für verteilte Anwendungen die von den Grundsätzen des World Wide Web, insbesondere des HTTP-Protokolls, abstrahiert und ein Modell für Erweiterungen anbietet.

    REST beschreibt ein Anwendungs-Modell, das Web Standards in einer Web gerechten Weise einsetzt.

    Ressourcen

    Web Seiten, Bilder und CGI Skripte bzw. Servlets stellen Resourcen dar, die über URLs adressiert und angesprochen werden können. Die direkte Bearbeitung einer Ressource ist nicht möglich, stattdessen werden HTTP-Anfragen an die Resourcen gesendet.Von zentraler Bedeutung sind dabei die folgenden, CRUD (Create, Read, Update, Delete) kompatiblen HTTP-Methoden:

    • POST - Erstellt eine neue Ressource
    • GET - Ruft die Daten der Ressource ab
    • PUT - Ändert die Ressource
    • DELETE - Löscht die Ressource

    Mit diesen einfachen Methoden ('Verben') wird festgelegt welche Aktion an der Ressource auszuführen ist. Das einfachste Beispiel einer solchen Anfrage ist das Abrufen einer Seite im Browser. Dabei wird die HTTP-Methode 'GET' auf eine durch die URL definierte Ressource angewandt und die im HTML-Format gelieferten Daten werden im Browser angezeigt.

    Darstellung

    Eine Ressource sollte ihre Daten auf verschiedene Weise zur Verfügung stellen können. Möglich wären Darstellungen im HTML-, XML-Format, PDF, Grafik oder andere. Wichtig ist, dass Client und Server ein Format aushandeln können, das beide verstehen.

    Zustandslose Kommunikation

    Der Informationsaustausch erfolgt in der REST-Architektur grundsätzlich zustandslos, dass heißt es müssen durch den Server keine Daten über die letzte Anfrage des Client's vorgehalten werden. Der Client muss bei jeder Anfrage alle für die Verarbeitung der Anfrage benötigten Informationen übergeben. Infolge dieses Prinzips sinken die vom Server benötigten Systemressourcen drastisch und die Skalierbarkeit einer Anwendung erhöht sich stark.

    Der Client hangelt sich von Zustand zu Zustand.

    Indem er die durch den Server aufgezeigten Optionen / Zustandsübergänge (z.B. Links) nutzt kann der Client seinen Zustand ändern und sein Ziel erreichen. Wichtig ist, dass dem Client durch den Server alle nötigen Informationen zur Verfügung gestellt werden, damit er den nächsten Schritt einleiten kann.