26.12.2014 Aufrufe

img - GitHub Pages

img - GitHub Pages

img - GitHub Pages

MEHR ANZEIGEN
WENIGER ANZEIGEN

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.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!