Philipps paper equivalent Blog

Ich habe lange Zeit nicht mehr gemeldet. Das lag zum einen daran, dass es viel drumherum zu tun gab und zum zweiten daran, dass ich momentan viele vage Dinge habe, die ich erstmal in eine wirkliche Form bringen will. So ungefähr wie eine Zettelsammlung, die man dann endlich Llochen und einheften möchte.

Ich fange erstmal damit an, dass ich meine - bisherigen - Funktionen zu meinen Objekten sortiere. Bisher habe ich an Objekten nur User und Entries. Wohlgemerkt, es geht hier nicht um Methoden sondern einzig und alleine um Funktionen. D.h. die Funktion wäre das was in der URI dann stehen würde. z.B. /Users/1/inbox. Dann wäre Users also mein Objekt (dies wird auf Java Ebene dann von der Klasse UserService abgebildet) und inbox wäre die Funktion. Natürlich wird es in der Klasse UserService eine Methode Namens inbox geben, allerdings auch zusätzliche Methoden, welche nicht dem REST Paradigma unterworfen sind.
Hier also meine kleine Übersicht:

• Entries
  • create
  • update
  • delete
  
  
  • send
  • list
  • mark
  
  
  • Dependencies
• Users
  • create
  • update
  • delete
  
  
  • login
  • logout
  • list
  
  
  • Inbox
  • Outbox

Eine Erklärung erfolgt in einem späteren Post. Sobald ich die einzelnen Funktionen eingegrenzt habe. Zudem haben sich folgende Änderungen ergeben:

1. Ein Eintrag kann mehrere Empfänger haben. Damit kommen folgende Problem auf mich zu:
a) Ist ein Eintrag erledigt, wenn ein Empfänger ihn als erledigt markiert? Oder alle? Vielleicht wahlweise? b) Wenn es möglich ist, Einträge "weiter zu vermitteln", wie stellt man sicher, dass die anderen Empfänger erhalten bleiben? Kann der aktuelle Empfänger weitere hinzufügen?
c) Wie bildet man das in der Datenbank ab (zum Glückt gibt es dafür ja schon eine geeignete Lösung)

Dazu gesellen sich dann noch Probleme, dass man zum Beispiel ja eindeutig einen aktuell Verantwortlichen für einen Eintrag ermitteln sollen kann. Bei wechselnden Empfängern und vor allem mehreren Empfänger könnte das schwierig werden. Vor allem müsste man dann auch über eine erweitere Rollenverteilung nachdenken. Stichwort Verantwortlich und Bearbeiter. 2. meistens ist es notwendig, dass eine Aufgabe in Unteraufgaben "aufgebrochen" wird. So soll es möglich sein, dass ein Eintrag beliebig(?) viele Untereinträge auf beliebig(?) tief verschachtelten Ebenen hat. Dazu wird man den "Erledigt Status" von "unten nach oben durchreichen" müssten. Wenn aus Entry 12 Entry 12.1 und Entry 12.2 erledigt sind, sollte auch Entry 12 als erledigt markiert sein.

Zu guter Letzt noch ein paar Links, die sich so fanden:

Ajax mit HTTP Basic Auth (YUI) [1] womit schon mal ein Problem gelöst ist, was in meinem Hinterkopf festsaß.
REST with JSP [2] irgendwie sehe ich nur noch innoQ - so langsam wird man paranoid :-). REST Web Services [3] ist ein schönes Beispiel zu REST und da wird auch der Unterschied zu SOAP deutlich.

nach langer Zeit der Stille, hier mal wieder ein paar neue Infos:

Ersteinmal vielen Dank für die beiden Kommentare im letzten Beitrag.... zwei Stück sind ja fast schon Rekord.
Aber es spiegelt sehr schön auch meine erste Reaktion auf das Rest Paradigma wieder:
Es dauert eine Weile, bis man sich selber klar wird, wie man die einzelnen Ressourcen einteilt und welche einzelnen Bereiche überhaupt interessant sind für einen Benutzer.
Filtert man zum Beispiel alle Einträge auf der Clientseite und schickt immer eine komplette Liste (was meiner Meinung nach dem ganzen System widerspricht) oder legt man gleich separate "Views" für ein- und ausgehende Einträge an (was ich jetzt tatsächlich auch so machen werde).

Auf anraten von Phillip bin ich grade dabei die Grundprozesse zu sammeln und zu strukturieren. Also anders als die Grundfunktionen möchte ich hier dann auch die Vorgänge im System sammeln.

Also wenn zum Beispiel ein neuer Benutzer angelegt wird, wird erst ein Formular geladen, indem der Nutzer seine Daten einträgt, dann werden die Daten auf Stimmigkeit und Vollständigkeit überprüft und ggf. eine Fehlermeldung zurück gesendet. Es folgt eine Bestätigungsemail an den Ersteller, welche dieser nutzt, um seinen Account letztendlich zu aktivieren. Schon hier sind Fragen offen: zum Beispiel, soll es die Möglichkeit geben, dass nur ein Admin/Projektleiter neue Benutzer anlegen kann. Erhält ein Verantwortlicher eine Email über die Erstellung eines neuen Nutzers, sodass dieser in eine bestehende Gruppe (oder ein bestehendes Projekt) eingeordnet werden kann?

Ich denke das ich ein wenig Zeit investieren muss, aber dass sich diese Zeit definitiv auszahlt am Ende.
Ich werde meine Arbeit übrigens unter dem Titel

"Aufgaben kollaborativ und webbasiert verwalten- Realisierung einer Web-Anwendung mit Enterprise Java Beans und Yahoo Web Framework"

morgen anmelden. Vielen Danke für den Input Phillip :-). Gefällt mir so wirklich besser. Ab dann läuft die Zeit :-o.

Ich bin - eher durch Zufall auf folgendes Video von Stefan und Phillip gestoßen und nach dem Ansehen sind mir ein paar Dinge glasklar geworden:

Bisher hatte ich gedacht, dass REST eher als eine Art Spezialfall von HTTP ist. Seltsamerweise scheint es demnach allerdings anders herum der Fall zu sein.
Irgendwie machen jetzt auch die beiden letzten Kommentare mehr Sinn.

Ich halte die Darstellung des REST Prinzips für äußerst gelungen und hat mich seltsamerweise auch eine ganze Ecke mehr für RoR eingenommen. (Wer kann kann schon anzweifeln, wenn eine Applikation das Potential auf eine Skalierung (durch die Möglichkeit Ressourcen auf unterschiedliche URIs zu verteilen) quasi btw. eingebaut hat.

Ich werde morgen die Aktionen der verschiedenen Ressourcen auf die 4 Funktion POST/GET/DELETE/PUT abbilden.

Ich denke ich werde mich vorerst auf die Serverseite konzentrieren und als Ausgabetypen erstmal einfaches HTML und XML (welches ist ja später für YUI sowieso brauche) bemühen. Unter [1] gibt es auch schon einen Ansatz wie man die URIs dann auch ansteuern kann.

Was wir noch klar geworden ist und mich wirklich bestärkt hat ist, dass ich ein und dieselbe Anwendung als Teilstück auf eine bestehende Webseite einbinden kann (z.B. durch JS).
Allerdings bleiben ein paar Fragen, die sich während des Videos ergeben haben:

1. Ich habe vor einfache HTTP Authentifizierung (Basic Authentication nach RFC 2617) zu benutzen. Stefan meinte ja in dem Video, dass man - um die Zustandslosigkeit zu erhalten - die Authentifizierung bei jedem Zugriff erfolgen soll. Ist das durch die Spezifikation von Basic Authentification gewährleistet? Wenn ich muss lese ich das in der RFC auch nach ;-). Ich habe bisher halt eher mit Sessions gearbeitet und diese als SessionIDS an die URLS angehängt (was ja REST irgendwie wiederspricht - wäre eine Ressource ja nicht mehr eindeutig durch eine URI identifizierbar)

2. Bis auf Downloads habe ich mit curl noch nicht viel gemacht. Gibt es da irgendwo ein Tutorial zu? Grade so Möglichkeiten wie den Header zu ändern suche ich schon lange. Bisher habe ich - wenn ich den "Reintext" aus Abfragen erhalten wollte immer Telnet bemüht.

3. Als Stefan das XML Schnippsel gesendet hat, ist auf der Auflösung des Videos nicht wirklich ersichtlich welche URI jetzt aufgerufen wird. Meiner Meinung nach müsste es ja Customer (glaube der bekam die neue Stadt) und ein PUT (weil Veränderung) gewesen sein, aber vielleicht könnte ich das noch bestätigt bekommen :-)

4. Mit den Conditional Headern: Das klingt in erster Linie ein wenig nach gestreckter/gehackter Spezifikation. Ist das eine gängige Praxis oder dient das wirklich nur zur Behandlung von ganz harten Fällen?

Abschließend noch mal ein Kompliment an Stefan und Phillip. Irgendwie haben mir die nächtlichen 45 min grade eine ganze Menge weitergeholfen. Solche Videos sollten zu Youtube ;-).

Ich bin dann mal kurz für zwei Tage in England um mich zum Bachelor machen zu lassen :-D. Nur damit sich keiner Sorgen macht, dass hier nichts mehr kommt...

Ich bin momentan - ja immer noch - dabei meine Funktionen zu sammeln und auf REST Basis meine Schnittstellen zu definieren.
Ich hoffe, dass dann bald zum Abschluss zu bringen und dann erste Vorgänge zu implementieren.

Hier dann mal eine Übersicht, wie ich REST auf meine Anwendung hin abbilden möchte:

Das deckt sich auch ungefähr mit meinen Use-Cases. Ich werde jetzt versuchen eine Java Bean mit REST Funktionalität anzulegen um damit dann mein JPA Objekt zu bearbeiten :-).
Weiterhin muss ich mir noch stark überlegen, ob ich dann überhaupt noch JSP für die Darstellung brauche, oder ich nicht alles über Beans machen kann. (Wobei ich eigentlich gerne für die Display Logic - also die reine "Verpackung" bei JSP bleiben würde). Ich denke ich werde als Ausgabeformat der Resourcen(listen) ersteinmal bei XML bleiben, wobei sich als User natürlich auch anbieten würde, auch VCard anzubieten (aber ich muss ja in meinem Bereich bleiben :-) )

Bevor ich dann endlich mal wieder etwas über meine eigentliche Arbeit poste, noch mal ein kleiner Abstecher zu dem Thema "Dinge die man nebenher sich aneignet".
Ich habe mich mal, nach dem Kommentar von Stefan bezüglich JRA umgesehen.
Leider fand ich zuerst nur eine Source Version vom JRA Code, sodass ich mir erstmal die Fähigkeit aneignen musste, das ganze zu kompilieren.
Als Build Tool kommt hier übrigens Maven 2 zum Einsatz.
Das ganze ist vom Apache Projekt und soll wohl irgendwann einmal die Nachfolge von Ant antreten. Wenn man sich so die Feature PlugIns Liste ansieht, ist das auch durchaus wahrscheinlich.

Der riesen Vorteil von Maven 2 - soweit ich das bisher verstanden habe - ist, dass man die Tools, welche man zum Erstellen/Installieren/Testen/Deployen benutzen will, nicht vorher installieren muss, sondern dass Maven 2 von der Versionierung der Sourcen bis hin zum letztendlichen Kopieren auf das Zielsystem alles übernimmt.

Um es kurz zu machen: Ich erhielt dann nach viel Installation und Tutorials lesen endlich meine jra-1.0-alpha-5-SNAPSHOT.jar :) . Nachdem ich dann noch mal auf der JRA Homepage gesucht habe, habe ich allerdings gesehen, dass es eine alpha 4 auch zum Download gibt. Nunja bin ich zumindest ein wenig aktueller. Jetzt will ich mal schaun, dass ich die Jar einbinden und mit meinem bisherigen Projekt zum Laufen kriege.

Nachdem ich nun meine JRA jar habe und auch die restlet jar habe (Ich denke mir einfach mal, dass die vorausgesetzt wird). Habe ich mir nun eine einfache Klasse geschrieben (okay sie ist geklaut, aber ich will ja erstmal testen, wie was geht ^^):

package de.hausswolff.cotodo.test;

import java.util.List;

import org.codehaus.jra.*;

@HttpResource(location=”/customers”) public class Customers {

private List<Customer> registry;
public Customers(){
    this.registry.add(new Customer("bob"));
    this.registry.add(new Customer("alice"));
    this.registry.add(new Customer("carol"));
    this.registry.add(new Customer("dave"));
}
@Get
List<Customer> get(){
    return registry;
}

@Post
void add(Customer customer){

}

}

Okay… die Klasse wird anstandslos kompiliert und auch Eclipse kennt alle Annotation (dient wahrscheinlich nur zu meiner Beruhigung, sagt es mir doch, dass die jar richtig eingebunden ist :-D ).

Was ich mich jetzt allerdings frage ist, wie ich das schöne Teil nun einbinde. Da es ja von Aufbau her nicht wirkliche eine Bean ist. Ich habe versuchsweise in der web.xml folgendes eingefügt:

<servlet>
    <servlet-name>JRACustomers</servlet-name>
    <servlet-class>de.hausswolff.cotodo.test.Customers</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>JRACustomers</servlet-name>
    <url-pattern>/customers*</url-pattern>
</servlet-mapping>

Allerdings half das auch nicht. Unter /customers ist nix :-(. Ich werde mich damit morgen in aller Ruhe noch mal befassen. Als weiter Möglichkeit, dachte ich mir, dass ich die Class per jsp useBean Tag einbinden kann, aber ist ja auch keine wirkliche Bean. Ich hoffe, dass ich da morgen weiter mit komme. Im Netz fand sich bisher auch nix. Und auf der JRA Page wird nur nach paranamer verwiesen. Was das nun schon wieder ist, werd ich mir morgen/gleich mal anlesen.