Diskussion:Representational State Transfer

message: 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)
thread_title:  Englischer Artikel 

message: Warum ist URL rewrite nicht REST-konform?
Für den Client kann dadurch doch durchaus eine REST-Konforme URL-Struktur entstehen?
Klient <-> Client? Eine einheitliche Schreibweise wäre schön
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.
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)
replies: text: Ich glaube, ein derartiger Vergleich wäre ziemlich esoterisch. Alle genannten Stichworte hängen wohl eher von der konkreten Implementation als vom Paradigma ab. --91.58.124.179 10:23, 1. Mär. 2023 (CET)
thread_title: Rewrite

message: 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ß
In dem Abschnitt über die Eigenschaften fehlt die sechste: Cachable
--81.26.173.65 08:58, 26. Okt. 2011 (CEST)
thread_title:  Inkonsistenz 

message: # Mit POST werden neue Daten/Ressourcen auf dem Server abgelegt.
# 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)
thread_title:  Methoden 

message: 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)
thread_title:  Allgemeinverständlichkeit 

message: 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)
thread_title: Verwendung von Hypermedia

message: 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)
thread_title:  Der Abschnitt "Wohldefinierte Operationen" ist Käse 

message: 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)
replies: text: Das ist allerdings irrelevant, da REST gar keiner Norm unterliegt --80.147.30.138 13:56, 2. Mai 2014 (CEST)

text: 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)
replies: text: 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)
thread_title:  Definition von REST 

message: 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)
replies: text: „Finally, I describe the lessons learned from applying REST to the design of the Hypertext Transfer Protocol ….“ Mit diesem allgegenwärtigen Beispiel kann wohl jeder etwas anfangen. --84.157.226.12 21:52, 14. Apr. 2016 (CEST)
thread_title:  Vorschlag: Beispiele hinzufügen 

message: 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)
thread_title:  Vorschlag: Beispiele präzisieren 

message: 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)
replies: text: „Finally, I describe the lessons learned from applying REST to the design of the Hypertext Transfer Protocol …“ Mit dieser allgegenwärtigen Implementierung wäre wohl zu beginnen. --84.157.226.12 21:52, 14. Apr. 2016 (CEST)
thread_title:  Liste bestehender Implementierungen/Frameworks 

message: 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)
thread_title:  Katastrophe 

message: 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)
thread_title:  "Client-Server ...  Der Hauptvorteil dieser Anforderung ist die einfache Skalierbarkeit der Server, ..." WTF? 

message: Ich bin oft schwer begeistert von ChatGPTs Schreibstil. Hier ein positives Beispiel, das mir ziemlich genau die (für mich ausreichende und verständliche) Antwort gegeben hat, die ich mir gewünscht hatte:
Was bedeutet "REST" im Zusammenhang mit der Entwicklung von Webseiten?
"Im Zusammenhang mit der Entwicklung von Webseiten steht "REST" für "Representational State Transfer". Es handelt sich um ein Architekturstil für Netzwerkanwendungen, der in der Regel bei der Entwicklung von Webdiensten verwendet wird.
REST basiert auf dem HTTP-Protokoll und stellt eine Reihe von Prinzipien und Konventionen bereit, um die Kommunikation zwischen Client und Server in verteilten Systemen zu vereinfachen. Es legt fest, wie Ressourcen über eindeutige URLs (Uniform Resource Locators) angesprochen und manipuliert werden können.
 
Ein RESTful-Webservice ermöglicht es Clients, auf Ressourcen zuzugreifen und mit ihnen zu interagieren, indem sie HTTP-Methoden wie GET, POST, PUT und DELETE verwenden. Diese Methoden werden verwendet, um Daten abzurufen, zu erstellen, zu aktualisieren und zu löschen.
Ein weiteres wichtiges Merkmal von REST ist die lose Kopplung zwischen Client und Server. Der Server stellt die Daten als Repräsentationen (z. B. JSON oder XML) bereit, und der Client entscheidet, wie er mit diesen Daten umgehen möchte. Der Server speichert keinen Zustand über die einzelnen Anfragen hinweg, was zu einer skalierbaren und einfachen Architektur führt.
REST hat sich zu einem weit verbreiteten Ansatz in der Webentwicklung entwickelt und wird von vielen großen Webdiensten wie Twitter, Facebook und Google verwendet. Es ermöglicht die Erstellung von skalierbaren und interoperablen Systemen, bei denen verschiedene Clients auf die gleichen Ressourcen zugreifen können." --178.9.55.53 13:44, 9. Jun. 2023 (CEST)
thread_title:  Eine verständlichere Einführung von ChatGPT