img - GitHub Pages
img - GitHub Pages
img - GitHub Pages
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
4.5. RP4 Link 66<br />
Diskussion<br />
“RP3 HTTP” ist eine Richtlinie, welche nach Auffassung des Projektteams nur hinsichtlich<br />
der Formulare bereichernd für den Konzeptkatalog ist. Die restliche REST Thematik<br />
ist schon mit RP1 REST abgedeckt und sollte somit hinlänglich thematisiert worden sein.<br />
Die Verwendung von “PUT”, “DELETE” etc. für Formulare hat sowohl gute wie auch<br />
schlechte Seiten: Einerseits können die gleichen API-Routen (und somit der gleiche Code)<br />
wie für normale API-Aufrufe verwendet werden. Dafür ist allerdings ein Workaround<br />
notwendig.<br />
Falls die eigene Applikation komplett mittels einer REST-API aufgebaut wird ist diese<br />
Hilfskonstruktion sicher ein gehbarer Weg.<br />
4.5. RP4 Link<br />
Das “Link-Prinzip” ist eng verbunden mit Abschnitt 4.11, “RP10 Browser-Controls” und<br />
stellt die Anforderung, dass jede Seite eindeutig per URL identifizierbar sein muss.<br />
Wenn Web-Applikationen diesem Prinzip nicht folgen (bspw. Digitec [Dig]), dann können<br />
Seiten nicht per Link mit Freunden geteilt werden. Dies ist für Nutzer häufig nicht<br />
nachvollziehbar und die User Experience leidet damit.<br />
Bevor Browser die History API [Mozd] implementiert haben, konnte das Prinzip für<br />
JavaScript-lastige Webseiten nur schwer eingehalten werden.<br />
Geplante Umsetzung<br />
Die Beispielapplikation soll eindeutige URLs für Ressourcen verwenden. Dies soll sowohl<br />
für die REST-API gelten, wie auch für die Webseite.<br />
Konkrete Umsetzung<br />
Weil die Beispielapplikation so oder so den REST-Prinzipien entspricht, ist diese Richtlinie<br />
ein Muss.<br />
Jede URL entspricht einer eindeutigen Ressource und kann angesprochen werden.<br />
Mithilfe der History API [Mozd] wird auch auf dem Browser die URL geändert, obwohl<br />
u.U. nur ein AJAX-Request gemacht oder die View gewechselt wurde.<br />
Diskussion<br />
Schon Tim Berners-Lee hat vor Jahren geschrieben: “Cool URIs don’t change” [Ber].<br />
Damit eine URI “cool” ist, muss sie zuerst vorhanden und funktional sein.<br />
Auch aus einem weiteren Grund sind URIs nur dann “cool”, wenn sie vorhanden sind<br />
und niemals ändern: Mit den heutigen Möglichkeiten des “Sharing” auf diversen Sozialen<br />
Netzwerken muss es möglich sein, direkt auf die momentane Seite verlinken zu können.<br />
Das Projektteam ist davon überzeugt, dass diese Richtlinie umgesetzt werden muss.