Diskussion:Representational State Transfer

aus Wikipedia, der freien Enzyklopädie

Dieser Artikel ist eine einzige große Katastrophe

Tut mir leid für die reißerische Überschrift aber das musste ich jetzt mal loswerden. Vieles was im Artikel steht ist schlicht falsch. Ich kenne mich zwar mit REST recht gut aus habe aber wenig Erfahrung mit dem Schreiben in der Wikipedia. Deshalb trage ich hier mal ein paar Kritikpunkte zusammen.

Schon der erste Satz "[REST] bezeichnet ein Programmierparadigma für Webanwendungen" ist einfach falsch. REST ist ein Architekturstil für verteilte Hypermedia-Systeme ("Representational State Transfer (REST) [is an] architectural style for distributed hypermedia systems"). Der zweite Satz "Es gibt keine explizite Norm, daher gehen die Vorstellungen, was REST ist, auseinander" ist genauso schlim, da genau das Gegenteil wahr ist. REST ist ein Fachbegriff der duch die Dissertation von Fielding definiert wurde. Im Gegensatz zu vielen anderen Bezeichnungen der angewandten Informatik, wie z.B. Service-Orientierte-Architektur oder Web-Service, ist REST sehr klar definiert. (Verwunderlich das sowas überhaupt geschrieben wird. Man hätte Herrn Fielding doch wohl kaum eine Ph. D. verliehen wenn er in seiner Arbeit nur irgendwas ungenaues geschwafelt hätte.). Der nächste Satz ist nicht nur inhaltlich Quatsch sonder auch kaum verständlich:

„Im Grunde bezeichnet REST die Idee, dass eine Internetadresse (URL) genau einen Seiteninhalt als Ergebnis einer serverseitigen Aktion (etwa das Anzeigen einer Trefferliste nach einer Suche) darstellt, wie es der Internetstandard HTTP für statische Inhalte bereits vorsieht, ein Ziel, das für dynamisch erzeugte Seiten mitunter jedoch zusätzlichen Aufwand erfordert.“

Der nächste Absatz scheint völlig unmutiviert zu sein. Der Bezug von Lesezeichen zu REST ist keinesfalls klar. Hier wird der Leser nur verwirrt. Beim Lesen der abschließende Aussage das eine "gewisse Form der Bedienbarkeit der Anwendung in der Regel gewünscht" ist wusst ich nicht so recht ob ich lachen oder weihnen soll. Aber der Autor hat schon recht: Is immer jut wenn man dat Ding och bedienen kann.

Der nächste Absatz im Abschnitt "Geschichte" ist faktisch soweit korrekt. Der zweite Absatz ebenso, hat aber nichts mit der Geschichte von REST zu tun, sondern eher eine Bewertung der Bedeutung von REST und eine Erläuterung des Entstehungprozesses von REST.

Der folgende Absatz "Prinzipen" (der Name "Prinzipen" ist hier meines Erachtens irreführend. "Eigenschaften" wäre wahrscheinlich besser) behauptet das es sechs Eigenschaften gibt die ein REST-konformer Dienst ausmachen. Geht man davon aus das die sechs aufgezählten Eigenschaften tatsächlich REST-spezifisch sind und stellt dann noch fest das ganz wesentlich ("cacheable", "layered, ...) vergessen wurden, dann haut das mit den sechs leider nicht mehr hin. Die Aussage das es sich um sechs Eigenschaften handelt ist schlicht falsch.

Der nächste Absatz "Adresierbarkeit" geht in die richtige Richtung. Leider nutzt er viele REST untypische Ausdrücke wie z.B. Dienst oder Webservice die den Leser vom eigentlciehn Kern ablenken. (Was ist hier mit Dienst eigentlich gemeint? Kann eine statische Web-Seite auch ein Dienst sein? Und was haben REST-konforme Dienste mit Webservices zu tun?) Des Weiteren hebt er nicht hervor das URIs nur eine mögliche (wenn auch sehr gebräuchliche) Umsetzung von Resourcenbezeichnern sind.

Der Absatz "Unterschiedliche Repräsentationen" ist OK. Allerdings kann hier die Erwähnung des Webbrowsers den Leser in eine falsche Richtung lenken, da sie sugerriert das REST-konforme Dienst ausschließlich zur Mensch-Maschine-Kommunikation eingesetzt werden und somit von einem wesentlichen Nutzen von REST ablenken.

Der Absatz "Zustandslosigkeit" suggeriert wiederum das REST die Nutzung von HTTP bedingt. Ferner vermischt er den Aspekt der Zustandslosigkeit mit der der selbstbeschreibenden Nachrichten ("self-descriptive messages").

Unter dem Absatz "Operationen" wird nun die Behauptung aufgestellt das "REST-konforme Dienste [...] einige Operationen vorsehen, die auf alle Dienste (Ressourcen genannt) angewendet werden können". Diese Aussage ist stark missverständlich. Hier sollte die Notwendigkeit einer einheitlichen Schnittstelle im Vordergrund stehen und der Leser nicht mit dem Verweiß auf irgendwelche ominösen Operationen verwirrt werden. Im folgenden wird dann wieder ausschließlich über HTTP geschrieben was den Eindruck erweckt REST bedinge HTTP oder sei gar mit HTTP gleichzusetzen.

Der abschließende Absatz "Verwendung von Hypermedia" ist meines Erachtens OK. Allderings sollen die Begriffe "Anwendungsinformationen" und "Zustandsveränderung" ersetzt oder zumindest erläutert werden.

Wie schon ober erwähnt fehlen hier noch eine ganze Reihe von wichtigen Eigenschaften.

Der Abschnitt "Umsetzung" wird jetzt wieder richtig übel. Die Aussage "REST vereinheitlicht die Schnittstelle zwischen Systemen" ist so formuliert irreführend. Die Tatsache das REST eine einheitliche Schnittstelle bedingt sollte weiter oben abgehandelt werden. Auch der Nebensatz das die Schnittstelle das "zu erwartenden Verhalten" spezifiziert ist irreführend. Natürlich macht die das, sonst wärs ja keine Schnittstelle. Darüber hinaus muß eine Schnittstelle zwischen verteilten Systemen aber auch noch andere Dinge, wie zum Beispiel die Syntax von Methodenaufrufen festlegen. Das hat aber wenig mit REST zu tun, sondern mit Softwareschnittstellen verteilter Systeme im Allgemeinen. Auch die Bedeutung der Begriffe "standardisiert" und "Verben" werden in diesem Zusammenhang nicht erleutert und verwirren daher stark. Der nächste Satz ("Welche Aktionen dies sind, ist in REST nicht festgelegt, aber alle Aktionen sind allgemein definiert") ist schlicht wiedersprüchlich.

Im Folgenden wird nun HTTP erläutert. Das geschieht aber sinnvollerweise bereits unter dem Wiki-Artikel "HTTP" und hat hier in der Ausführlichkeit nicht verloren, da dadurch insbeonsere wieder die Abgrenzung von HTTP zu REST verloren geht. Der letze Absatz im Abschnitt "Umsetzung" ist wieder extrem irreführend. Was bitte sind "Methodeninformationen" und wie bitteschön bildet man die Funktionalität einer Resource über HTTP-Methoden ab (und warum wird das nur versucht)?

Der Abschnitt "Sicherheit" hat wiederrum nichts mit REST zu tun, wenngleich es durchaus interessant wäre mal zu untersuchen in wie weit sich Eigenschaften von REST auf die Sicherheit solcher Systeme auswirken. In diesem Abschnitt wird auf jeden Fall nur HTTP betrachtet. Und diese Betrachtung sollte unter dem Wiki-Artikel "HTTP" durchgeführt werden.

Was der abschließende Abschnitt "Abgrenzung zu anderen Kommunikationsmechanismen" mir sagen soll weiß ich nicht. Er grenzt auf jeden Fall nichts ab.

So jetzt hab ich aber mal auf die Kacke gehauen ;). Aber mal im Ernst: Der Artikel ist einfach nur schlecht.

Gibts hier noch ein paar Leute (die evtl. mehr Erfahrung in der Wikipedia haben) und denen dran gelegen ist den Artikel mal komplett zu überarbeiten?

(nicht signierter Beitrag von 193.159.70.152 (Diskussion) 12:52, 2. Jan. 2012 (CET))

  1. REST ist kein Architekturmuster, sondern ein Paradigma. Insofern stimmt der erste Absatz.
    1. Zum einen habe ich nie behauptet das REST ein Architekturmuster ist.
    2. Zum anderen ist es auch kein Paradigma
    3. Es ist ein Architekturstil. Dies kann auch wohl kaum zu Diskussion gestellt werden, da der Autor, der REST definiert hat eben das ganz klar schreibt: "Representational State Transfer (REST) [is an] architectural style for distributed hypermedia systems" (Seite 3, Absatz 3, Satz 1 [1]) (nicht signierter Beitrag von 146.60.235.229 (Diskussion) 19:56, 18. Apr. 2013 (CEST))
  2. der zweite Absatz gehört zu Clean URL und sollte hier entfernt werden.
  3. die Bezeichnung "Prinzipien" ist so richtig
  4. die Addressierbarkeit muss wohl näher erläutert werden. hier fehlt noch eine Definition für die Addressierung von REST-Elementen mit URIs. Auch wird URI und URL immer wieder verwechselt.
  5. den Artikel überarbeitest am besten immer selber - immerhin bist du selbst derjenige der das meiste Interesse daran hat das der Artikel stimmt und nicht andere. Sei Mutig!
Das habe ich bereits mehrfach gemacht. Alle meine Änderungen wurden wieder entfernt. Also hab ich das nächste Beste getan und die Mängel des Artikels hier aufgelistet. So kann der interresierte Leser dieser Mängel zumindest hier erkennen. (nicht signierter Beitrag von 146.60.235.229 (Diskussion) 19:56, 18. Apr. 2013 (CEST))
— MovGP0 22:52, 10. Apr. 2013 (CEST)

Ich habe die Seite in den letzten Tagen bereinigt, wobei die obige Mängelliste sehr hilfreich war. Die meisten Mängel waren von anderen Autoren bereits behoben. Ein generelles Problem des Textes war, dass REST eine Abstraktion des WWW darstellt und deshalb bestimmte Details nicht festlegt. Das Fehlen von Detailvorschriften war im Text so oft erwähnt worden, dass die Lesbarkeit, Präzision und wohl auch Glaubwürdigkeit darunter gelitten haben. Meiner Ansicht nach kann der Wartungsbalken nun aus dem Artikel entfernt werden.

In der Frage, ob es sich um ein Architekturmuster oder ein Programmierparadigma handelt, neige ich zu letzterem. Der Begriff Architekturmuster gaukelt eine Wertigkeit vor, die er angesichts der unterschiedlichen Definitionen des Architekturbegriffs allgemein und in der Informatik im Besonderen nicht besitzt. Von einem Programmierparadigma zu sprechen, ist inhaltlich nicht verkehrt, und außerdem lassen sich darunter auch Architekturmuster (beim Programmieren) subsumieren.

Joachim Schnitter (Diskussion) 16:17, 13. Aug. 2014 (CEST)

Habe den Wartungsbalken heute entfernt.

Joachim Schnitter (Diskussion) 17:23, 13. Jan. 2015 (CET)

Englischer Artikel

Hast du den englischen Artikel mal angeschaut? Ist der besser? Ich überlege ob es Sinn machen würde, einfach mal den Englischen Artikel ins deutsche zu übersetzen. -- Dratir (Diskussion) 11:48, 4. Jun. 2012 (CEST)

Rewrite

Warum ist URL rewrite nicht REST-konform? Für den Client kann dadurch doch durchaus eine REST-Konforme URL-Struktur entstehen? (nicht signierter Beitrag von Theonlyandy (Diskussion | Beiträge) 10:02, 23. Jul. 2007‎ (CEST))

Klient <-> Client? Eine einheitliche Schreibweise wäre schön (nicht signierter Beitrag von 17:27, 12. Aug. 2007‎ (CEST) (Diskussion | Beiträge) )

Der Artikel braucht noch einiges an Überarbeitung. Ich war so frei und hab den Anfang etwas verändert. Prinzipiell sollten wir unterscheiden zwischen dem REST Architekturstil und dessen Implementierung z.B. in Form von RESTful Web Services. (nicht signierter Beitrag von Nebu777 (Diskussion | Beiträge) 18:30, 2. Jan. 2008‎ (CET))

Was diesem Artikel noch fehlt, ist der Vergleich mit anderen Technologien; Vor- und Nachteile (Stichworte: Reliability, Interoperabilität, Sicherheit, Standardisierung, Orchestrierung). RIMOLA 21:35, 10. Feb. 2008 (CET)

Inkonsistenz

In einem Absatz wird erwähnt:

Jede Anfrage eines Clients an den Server ist in dem Sinne in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt werden. Dies gilt z. B. auch für Authentifizierungsinformationen; statt "login via cookie" wird in jeder URI z.B. ein Passwort-Hashcode übertragen.

Im Abschnitt Umsetzung steht dann:

Im Gegensatz zu vielen RPC-Architekturen kodiert REST keine Methodeninformation in die URI, da die URI die Ressource identifiziert (wie der Name es auch sagt) und nicht das, was mit ihr getan werden soll.

Gruß(nicht signierter Beitrag von 82.82.188.204 (Diskussion) 16:56, 1. Sep. 2008)

In dem Abschnitt über die Eigenschaften fehlt die sechste: Cachable --81.26.173.65 08:58, 26. Okt. 2011 (CEST)

Methoden

  1. Mit POST werden neue Daten/Ressourcen auf dem Server abgelegt.
  2. Mit PUT werden vorhandene Daten aktualisiert oder untergeordnete Ressourcen ergänzt.

Was solln das jetzt heißen? Mal abgehesen von "schwer verständlich" kommt kein Unterschied hevor. --85.178.141.131 00:15, 3. Nov. 2009 (CET)

-> ich hoffe, dass es jetzt verständlicher ist. (nicht signierter Beitrag von 217.233.172.19 (Diskussion) 06:36, 23. Sep. 2010 (CEST))

Allgemeinverständlichkeit

Ich habe den Artikel schon zwei mal gelesen und immer noch Mühe ihn zu vestehen. Folgende Punkte erschweren das Verständnis und könnte man verbessern:

1. Es gibt viele hochgestochene komplizierte Sätzen wie

"REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und – bezüglich des zu erwartenden Verhaltens – standardisierte Menge von Aktionen (=Verben)."

2. Der Artikel ist "Bottom-Up" aufgebaut, möglicherweise dem Aufbau der Dissertation folgend? Erst werden die Grundprinzipien erklärt, dann die Umsetzung. Die Einleitung ist zwar etwas allgemein formuliert, aber die einzige Aussage darüber, was RESTful Webservices auszeichnet, ist folgender:

"Während dessen Architektur durch den URI-Standard und HTTP beschrieben werden kann, legt der REST-Architekturstil nahe, jede Ressource mit einer eigenen URI anzusprechen."

Was unterscheidet sich hier von anderen Web-Services?

Die Einleitung oder der erste Abschnitt sollten deutlich machen, worin sich RESTful Webservices in praktischer Sicht von anderen Webservices unterscheiden, was das für Konsequenzen für die Verwendung hat etc.

3. Ich habe den Verdacht, dass für die Erklärung Begriffe herbeigezogen werden, die im REST-Kontext eine ganz spezifische Bedeutung haben. Wenn man die Bedeutung noch nicht kennt, versteht man auch die Erklärung nicht. Beispiel:

"REST-konforme Webservices machen die von ihnen zur Verfügung gestellten Daten unter Verwendung von Ressourcen zugänglich (...)"

Für mich sind zur Verfügung gestellte Daten Ressourcen. Was soll dann der Satz bedeuten? Ressource kann übrigens auch Speicherplatz, Hardware, Bandbreite oder eine Person meinen, nur um klarzustellen, aus welchem Kontext der Leser kommt. Der einzige Schluss, den ich hier ziehen kann ist, dass "Ressource" im REST-Kontext anscheinend eine ganz spezifische Bedeutung hat, aber genau die kenne ich ja als Aussenstehender noch nicht.

4. Auch Widersprüche kommen vor, wie z.B.:

'"REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und – bezüglich des zu erwartenden Verhaltens – standardisierte Menge von Aktionen (=Verben). Welche Aktionen dies sind, ist in REST nicht festgelegt, aber alle Aktionen sind allgemein definiert."'

Gefolgt von einer klar abgerenzten Liste von Aktionen. Was soll dann die Aussage "Welche Aktionen dies sind, ist in REST nicht festgelegt?"

Gruss --Chiccodoro 09:39, 15. Sep. 2010 (CEST)

Verwendung von Hypermedia

In dem Abschnitt wird beschrieben, dass die Ressourcen Hyperlinks enthalten können, über die sie verbunden sind. Das hat aber mit RESTful gar nichts zu tun. REST definiert lediglich das Format (z. B. XML,Text, JSON), nicht die Inhalte. Der Abschnitt hat hier keine Berechtigung.

Pmatu 20:22, 6. Mai 2011 (CEST)

Das stimmt so nicht. Das Format hat nichts mit REST zu tun. Verlinkung hingegen schon. Vgl. bspw. bei Martin Fowler: http://martinfowler.com/articles/richardsonMaturityModel.html

-- Leifsinger 13:44, 13. Mai 2011 (CEST)

Der Abschnitt "Wohldefinierte Operationen" ist Käse

Die Aussage "REST sieht eine Menge wohldefinierter Operationen vor" ist, mal abgesehen davon das nicht klar ist was der Unterschied zwischen einer wohldefinierten und einer nicht wohldefinierten Operation ist, irreführend. REST ist keine Architektur. Dementsprechend beschreibt REST auch keine Schnittstelle, sondern lediglich Anforderungen ("Constraints") an die Schnittstelle einer konkreten Architektur, die diesem Architekturstil genügt. Ein Beispiel einer solchen Architektur ist das WWW, welches durch HTTP eine (fast) REST-konforme Schnittstelle besitzt. HTTP ist also nur eine mögliche konkrete Implementierung einer REST-konformen Schnittstelle! Die Anforderungen die REST an eine solche Schnittstelle stellt (z.B. Sicherheit und Idempotents) werden hier hinter HTTP verborgen. (nicht signierter Beitrag von 80.143.92.184 (Diskussion) 12:23, 8. Jul 2011 (CEST))

Chaos

Oi. Irgendwelche Studenten haben halb verstanden was das ist, und etwas zusammengeschrieben. Was dieses sein soll, erschließt mich nicht: 

REST-konforme Webservices differenzieren zwischen den Kategorien des Ressourcenzustands und des Anwendungszustands.
* Der Ressourcenzustand beinhaltet Informationen über eine Ressource, seine Verwaltung obliegt dem Server, 
der Client erhält  Informationen über den Ressourcenzustand ausschließlich über die ihm zugestellten Repräsentationen einer 
Ressource.
* Der Anwendungszustand bezieht sich auf die Position eines Clients innerhalb der Anwendung, die Verwaltung des
Anwendungszustandes obliegt dem Client. Im Gegensatz zu vielen RPC-artigen Architekturen 
hält ein REST-konformer Webservice zu keinem Zeitpunkt Informationen über den Anwendungszustand auf der Seite des 
Servers – z. B. in einer Sitzung – vor.

Ich fange an zu entwirren, die EN-Fassung ist da viel besser.

(nicht signierter Beitrag von WiseWoman (Diskussion | Beiträge) 22:04, 12. Sep. 2011‎ (CEST))

Definition von REST

In der Einleitung steht

Es gibt keine explizite Norm, daher gehen die Vorstellungen, was REST ist, auseinander.

Fielding selbst schreibt hierzu:

Anyone who claims that REST is something other than what is in my dissertation is just babbling nonsense -- the dissertation defined the term (and other people making it a buzzword won't change that). People are free to claim that there is more to "web architecture" than what I included in REST, and that perhaps some of that should have been included in REST, but REST itself is just a name chosen for a specific style that I defined [...]

Somit qualifiziert sich der Wikipedia-Artikel als "babbling nonsense". Man sollte klar machen, dass REST sehr genau in der Dissertation beschrieben ist, aber dass der Begriff oft missbräuchlich für irgendwelche Implementierungs-/ Architekturvarianten verwendet wird. --77.2.62.179 07:28, 25. Nov. 2011 (CET)

Eine Dissertation ist aber keine Norm. Insofern bestätigt Fielding, das "die Vorstellungen auseinander gehen" (seine und andere). -- 195.36.75.27 18:42, 12. Dez. 2011 (CET)

Das ist allerdings irrelevant, da REST gar keiner Norm unterliegt --80.147.30.138 13:56, 2. Mai 2014 (CEST)

Nein! Fielding definiert in seiner Dissertation ganz klar was REST ist (und damit natürlich auch was REST eben nicht ist)! REST ist exakt das was Fielding REST nennt. Das heißt ja nicht das es evtl. nicht sinnvoll wäre etwas hinzuzufügen, zu entfernen oder einfach anders zu machen. Das wäre dann aber nicht mehr REST, sondern würde einen anderen Namen tragen. (nicht signierter Beitrag von 193.159.70.152 (Diskussion) 14:36, 2. Jan. 2012 (CET))

Vorschlag zur Güte: Wikipedia sollte (jedenfalls ist das meine Wahrnehmung von diesem Portal) neutral und wertfrei informieren. Insofern wäre es doch indiziert zu nennen, dass Fielding den Begriff REST in seiner Dissertation klar definiert hat, es jedoch weitere Interpretationen gibt, die mitunter von der ursprünglichen Begriffsdefinition abweichen. Denn nur weil eine Person einen Begriff definiert hat, heisst das nicht zwangsläufig, dass die Definition keinem Wandel unterliegen darf. --217.234.199.2 09:54, 17. Mai 2014 (CEST)
Siehe was Wikipedia nicht ist. Nichts gegen „weitere Interpretationen“ gleich belegter Relevanz wie Fielding und die University of California, aber bitte keine Theoriefindung. --84.157.226.12 21:52, 14. Apr. 2016 (CEST)

Vorschlag: Beispiele hinzufügen

Ich finde es, insbesondere in der Welt der Informationstechnik, immer sehr hilfreich, wenn eine Sache bzw. ein Konzept anhand von Beispielen erklärt wird. Oft ist es dann auch sehr hilfreich, mittels Negativbeispiele abzugrenzen, was eine Sache oder ein Konzept nicht ist. Leider kenne ich mich zu wenig mit REST aus (ein Grund, warum ich auf den Wikipedia-Artikel gegangen bin), um diese Beispiele beitragen zu können. Vielleicht sieht ein Wissender das mit den Beispielen ja auch so, und kann aushelfen. --217.234.199.2 09:47, 17. Mai 2014 (CEST)

„Finally, I describe the lessons learned from applying REST to the design of the Hypertext Transfer Protocol ….“[2] Mit diesem allgegenwärtigen Beispiel kann wohl jeder etwas anfangen. --84.157.226.12 21:52, 14. Apr. 2016 (CEST)

Vorschlag: Beispiele präzisieren

Und zwar schlage ich vor, die Beispiele in dieser Fassung zu veröffentlichen.

Im Beispiel sieht man einen GET-Request, der Konto-Informationen im JSON-Format abruft: 

GET /accounts/123abc HTTP/1.1
Host: bank.example.com
Accept: application/json
...

Die Antwort bei einem ausgegliechenem Konto kann dann wie folgt lauten: 

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ...

{
   "account": {
      "account_id": "123abc",
       "balance": {
          "currency": "EUR",
          "value": 100.0
       },
       "links": {
          "deposit": "/accounts/123abc/deposit",
          "withdraw": "/accounts/123abc/withdraw",
          "transfer": "/accounts/123abc/transfer",
          "close": "/accounts/123abc/close"
       }
   }
}

Beispielantwort 1

Die Beispielantwort 1 beinhaltet vier mögliche Links: deposit (einzahlen), withdraw (abbuchen), transfer (überweisen) und close (kündigen). Wenn das Konto überzogen ist, kann nur noch Geld auf das Konto eingezahlt werden, aber keines mehr abgebucht oder überwiesen werden, und man kann das Konto nicht mehr kündigen. Die Antwort bei einem überzogenem Konto kann daher so aussehen: 

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ...

{
   "account": {
      "account_id": "123abc",
       "balance": {
           "currency": "EUR",
           "value": -100.0
       },
       "links": {
          "deposit": "/accounts/123abc/deposit"
       }
   }
}

Beispielantwort 2

Ich halte es für vorteilhaft, wenn die Beispielantworten 1 und 2 klar voneinander getrennt werden, um deutlich zu machen, dass eine gleichlautende Abfrage beim gleichen Konto zwei unterschiedliche Ergebnisse liefern kann - je nach Kontostatus, also "ausgegliechen" oder "überzogen". Diese Verdeutlichung, Trennung kann einem/-r technikfremden Leser:in helfen die Gebrauchseigenschaften eines "HATEOAS-konformen REST-Services als endlichen Automaten" zu verstehen - ohne in die technische Details sich zu vertiefen.

Limmette (Diskussion) 07:08, 23. Sep. 2021 (CEST)

Liste bestehender Implementierungen/Frameworks

Mir fehlt hier eine Liste von existierenden Implementierungen bzw. Frameworks, also z.B. Apache Wink, Apache CXF, Microsoft ASP.Net Web-API usw in tabellarischer Form, am besten mit weiteren Informationen zwecks Vergleich. Werde ich evtl. selber demnächst hinzufügen, man darf mir gerne zuvorkommen! ;-) --Joschi71 (Diskussion) 18:28, 23. Jul. 2015 (CEST)

„Finally, I describe the lessons learned from applying REST to the design of the Hypertext Transfer Protocol …“[3] Mit dieser allgegenwärtigen Implementierung wäre wohl zu beginnen. --84.157.226.12 21:52, 14. Apr. 2016 (CEST)

Katastrophe

Ich schließe mich den bereits vorhandenen Meinungen an, die darauf abzielen, daß der Artikel eher unbrauchbar ist. Da macht man seit mehreren Jahrzehnten Softwarenetwicklung, will kurz den Begriff klären und bekommt eine derartige Menge unverständlicher Sätze, die auch irgendwie nicht wirklich eine logische Kette bilden ... Frust. Das Ganze dann noch ohne Punkt, Komma oder Formatierung als trockener Fließtext durchgezogen ... Schon gleich nach dem Anfang springt es dann mitten rein in Details, statt daß man erstmal an der Oberfläche bleibt und die groben Dinge klärt.

Die Wikipedia ist für normale Menschen, nicht für Fachleute. Man kann es sich natürlich einfach machen, aber schöner wäre es, wenn man nicht gezwungen wäre, sich noch durch 12 Klicks auf Hyperlinks weitere und weitere Dinge reinzuziehen. Ich frage mich, wieviele Menschen das Wort "Programmierparadigma" (oder auch nur "Paradigma") aus dem Stand verstehen.

Da fängt die englische WP wesentlich zugänglicher an (wenngleich wohl auch nicht völlig korrekt in der Sache): "Representational state transfer (REST) or RESTful web services are one way of providing interoperability between computer systems on the internet. REST-compliant web services allow requesting systems to access and manipulate textual representations of web resources using a uniform and predefined set of stateless operations.". Das kann man direkt verstehen ! Nichtfachleute stolpern vielleicht über "stateless", aber das ist völlig sekundär. Man versteht sofort, worum es geht und wie es ungefähr gemacht wird.

Sorry, aber das schreit nach Neuanfertigung :-(. JB. --84.186.149.195 05:22, 1. Okt. 2016 (CEST)

allgemein verständliche Erläuterung gesucht

Im Text fehlt es an einer allgemein verständlichen Erläuterung, sowohl was die Definition einer REST API angeht, als auch deren Nutzung. So heißt es im Text an einer Stelle "Ziel ist die Einheitlichkeit der Schnittstelle und somit ihre einfache Nutzung." Alles, was ich in den letzten Wochen gelesen habe, ist selbst für Amateur-Programmierer sehr schwierig zu verstehen und ebenso schwierig umzusetzen. Meines Erachtens ist die Erstellung einer API alles andere als einfach, denn die Vielfältigkeit der Ausgestaltung ist enorm. Dadurch ergibt sich ein hoher Komplexitätsgrad. Hinzu kommt, dass auf dem Buchmarkt nur extrem wenig Fachliteratur in deutscher Sprache verfügbar ist. Das wundert mich, denn die Bedeutung von REST APIs wird mit zunehmender Digitalisierung deutlich zunehmen.

"Client-Server ... Der Hauptvorteil dieser Anforderung ist die einfache Skalierbarkeit der Server, ..." WTF?

Womit wird hier denn Client-Server verglichen? Einen Vorteil kann man nicht aus sich selbst heraus haben. Und nur weil man eine Client-Server-Architektur hat, muss der Server nicht einfach "skalierbar" sein. --85.199.68.80 16:01, 21. Jul. 2021 (CEST)

Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Representational_State_Transfer&oldid=215849316“