Die Entwicklung von REST und die METRO Design Sprache, haben sich bei mir in ASP.NET Web Anwendungen niedergeschlagen. Status Information wurde immer in Session Variablen abgelegt. Das hat den Nachteil, das man nicht beliebig an eine bestimmt Stelle der Anwendung springen kann, weil unter Umständen erst ein gültiger Status erzeugt werden muss. Das kann eine Benutzeranmeldung sein oder auch eine ID die intern benötigt wird.
REST ist in dem Sinne statuslos. Von Request zu Request muss aus der URI, den HTTP Header und den Body Daten ein bestimmter Zustand hergestellt werden.
In der Praxis ist dies ein längerer HTML Link, den man speichern kann, per Mail weiterleiten oder in einer neuen App Sharen wie die Windows 8.1 Leseliste.
Mit folgendem Link auf Bing Maps lässt sich in jedem Browser die Adresse der ppedv AG “wiederherstellen”. Einziger Mangel, der Link ist extrem komplex aufgebaut. Allerdings lässt sich dieser teilen und durch Base64 decodierung, der Inhalt des Suchfeldes wieder herstellen.
Weiteres Beispiel ist Facebook. Über den Link https://www.facebook.com/preishuber/posts/10152537880933957 erhalte ich mein Profil und ein ganz spezielles Post dazu.
Im Ergebnis sehen wir das eine URL nicht nur die Website, sondern auch deren Formularinhalte und die damit erzielten Ergebnisse rekonstruieren kann.
REST für Web Forms
In Kombination mit ASP.NET FriendlyUrls, die ohne die aspx Erweiterungen funktioniert, kann man dann ein Konzept erstellen um an bestimmte Stellen einer Anwendung direkt springen zu können. In HTML ein seit langem auch als deep linking bekannt.
| ASPX Seite | Parameter | Beschreibung |
| Kunden/ | search/begriff | Liste mit gefilterten Daten nach “Begriff” |
| Kundenedit/ | 12345 | Formular anhand der ID des Kunden im Editiermodus |
| Kundenedit/ | neu | Formular im Insert Modus |
| Ansprechpartner/ | 12345 | Alle Ansprechpartner zur Firma mit der ID 12345 |
| Ansprechpartner/ | 12345/67890 | Master Detail Ansicht von Firma, eines Ansprechpartners und evtl Kommentarliste |
Kunden/ | 12345/delete | Dies kommt nicht zum Einsatz, da es nicht nötig ist eine Status zu halten. |
Soll man nun mit Key Values ala search/begriff oder nur über den Index arbeiten? Da ASP.NET FriendlyUrls nur eine generische List of String liefert bei Request.GetFriendlyUrlSegments(), spricht viel für den Index. Meine persönliche Entscheidung ist das immer wenn eindeutige Werte in der URL erscheinen kein Key vorangestellt wird. Wenn eine Variable Ergebnismenge kommt, wie bei Suche, stelle ich den Key Search voran.
Navigation
Wie eingangs erwähnt, hat mich die METRO Design Sprache erheblich beeinflusst. Klares Layout, den Nutzen im Fokus und unwichtiges weglassen (nicht ausgrauen). Wesentlich ist auch das Konzept der Benutzerführung durch Navigation statt Menüs. Wenn man den Fluss genauer betrachtet und dazu ein Diagramm zeichnet (ja- Flussdiagramm)
Die Seite Kunden bietet zwei Funktionen, Suche und Liste. Man kann einen Kunden auswählen editieren und dann wieder zurück gehen. Dies über einen Backbutton wie es viele Apps, egal ob Phone oder Windows haben.
Hier ergeben sich zwei Detail Probleme, die es notwendig machen selbst eine Navigationslogik aufzubauen und sich nicht auf den Browser Back Button und dessen Historie zu verlassen.
Herkunft
In diesem Fall, erhält der Benutzer zwei Einstiegspunkte. Eine Suche über den Kunden und eine Suche über den Ansprechpartner. Da die Ergebnislisten unterschiedlich aussehen, in zwei verschiedenen ASPX Webform Seiten realisiert. So ist es nötig, bei der Ansprechpartnersuche die Firma als Spalte mit anzuzeigen, in dem Pfad von Kunden, ist die Firma klar und steht als Headline darüber.
Nun führen beide Wege auf ein einheitliches Edit Formular. Was bedeutet zurück an dieser Stelle? Der Browser zurück bringt den Benutzer wieder in den Zweig Ansprechpartner Suche.
Im Use Case neuen Ansprechpartner zur Firma hinzufügen, wird der logisch vorhergehende Schritt aber die Ansprechpartnerliste der Firma sein. Entsprechend verweist der Back Button in der Seite auf diese URL.
Statuslos oder doch Session?
Nachdem ich mit dem Konzept experimentiert habe, stellt sich raus, das es nicht nötig ist beliebig tief in die Funktion einer Anwendung zu verlinken. Bei Facebook ändert sich die Url nicht, wenn man einen Eintrag editiert. In meiner Musteranwendung ist das einfügen eines Kommentars zu einem Ansprechpartner (im Diagramm nicht ersichtlich) ohne eigene Page und damit auch REST Style URL. Da es nur sinnvoll ist diese Aktivität auszuführen, wenn der Benutzer vorher den Ansprechpartner aufgerufen hat, macht es sinn den Status zu speichern. Dafür kommen die üblichen verdächtigen wie Querystring, Cookie, Session Variable, Hidden Field ( Gruß vom Viewstate) in Frage.
Es hat sich gezeigt, das die URL und verschärft das einpacken in die FriendlyURL, die Navigation schwierig macht. Sowohl beim Aufruf einer Page müssen alle benötigten Segmente vorhanden sein, als auch bei der Weiterleitung per Link, korrekt aufgebaut werden.
Probleme
In diesem Beispiel bringt der Zweig über die Ansprechpartnersuche keinen Suchbegriff für die Kundensuche. Das bedeutet, das man bei Verwendung des Zurück Buttons Edit Ansprechpartner- Ansprechpartnerliste dann in Kundenliste steht, ohne nach einer Firma gesucht zu haben. Deshalb muss die Firma in der Uri als Segment eingefügt werden um eine Liste anzeigen zu können. Das lässt sich zwar implementieren erzeugt aber einen leichten Bruch im Fluss. Die Alternative ist, bei leerem Suchbegriff auf die Einstiegseite der Kundensuche zu verzweigen (ohne search). Dies hat aber den Nachteil, wenn der Bearbeiter in der Praxis weitere Recherchen in der Firma vornehmen möchte, nochmal nach der Firma suchen muss. Kein sehr verlockender Gedanke.