Written by on 2007-11-02

RESTliches

Personal

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:
    1. Ist ein Eintrag erledigt, wenn ein Empfänger ihn als erledigt markiert? Oder alle? Vielleicht wahlweise?
    2. 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?
    3. 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. eistens 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.

3 comments

  • Stefan Tilkov has written:

    Eine Funktion sollte definitiv nie in der URI stehen, wenn das ganze RESTful sein soll – d.h. Deine URIs sollten immer “Dinge” Identifizieren. Als Funktionen/Verben/Methoden hast Du nur GET/PUT/POST/DELETE und musst daher alles, was da tun möchtest, auf eine Kombination von Ressource + Standardmethode abbilden.
    Oder ist Dir das klar und ich habe Dich missverstanden?

  • Phillip Ghadir has written:

    Ich würde das REST-Design noch ein wenig anders auffassen wollen:

    /Users/1/inbox
    • “/Users” ist eine Ressource, die einfach eine Menge von Benutzern repräsentiert.
    • “/Users/1” identifiziert die Ressource des Benutzers mit der ID 1.
    • “/Users/1/inbox” identifiziert den Eingangskorb des Benutzers mit der ID 1. Der Eingangskorb ist selbst eine Ressource.

    Dir bleibt überlassen, wie Du die Funktionalität schneiden möchtest. Allerdings könnte es helfen, die Implementierung erst zu skizzieren, wenn Du die Schnittstelle (d.h. die Ressourcensicht) entworfen hast.
    Zwar wirst Du immer Rückkopplungen zwischen Schnittstellenentwurf und Implementierung haben, während Du entwickelst, aber den nötigen Transfer von Services und Operationen auf Ressourcen und URIs solltest Du nicht unterschätzen, denn die Ressourcerepräsentationen bekommen bei REST eine sehr große Bedeutung:
    Entweder Du wendest implizit oder explizit für komplexe Aufgaben das Befehlsmuster an, so dass eine (generische) Abbildung von der REST-Schnittstelle auf die klassische Implementierung Umbauten erfordert.
    Um den Aufwand dafür gering zu halten, sollte Du den Zustandsraum modelliert und verstanden haben, um eine Degeneration der Implementierung bei der unbedarften Erweiterung um Funktionalität zu vermeiden.
    Die REST-Grundlagen haben Stefan und ich einem Artikel in der ObjektSpektrum beschrieben. Das Buch SOA-Expertenwissen enthält ebenfalls 3 Artikel zu REST.

  • Mati has written:

    Hi
    You must clean comments..

Leave a Reply