Dienstag, 11. August 2015

REST mit G.

Vorsicht jetzt wird's technisch. Ich habe mich gerade 1,5h lang mit G. über Praktiken und Ideen unterhalten wie konkret REST-Schnittstellen in dem Server an dem ich gerade arbeite, realisiert werden bzw. werden könnten.
Dabei gab es für mich einige Aha-Effekte, obwohl einiges trivial klingt, habe ich nie so rigoros darüber nachgedacht:



  1. PUT ohne Identifier kann es nicht geben! Wenn ein Identifier erzeugt wird, muss das mit dem POST-Verb geschehen. Im LocationHeader (neu für mich) wird dann die URI der erzeugten Resource zurückgegeben. ... ich muss unbedingt noch feststellen, wie der LocationHeader sinnvoll in der Response erzeugt wird.
  2. AktionsUris: es sollte nicht zuviel implizit durch das setzen von Werten (z.B. über JSON) passieren. Man hängt an die Ressource in diesem Fall eine Aktionsuri wie z.B. "starts" und mit POST wird hier ein Aktion zum starten der Ressource erzeugt. Die Aktion stellt selbst wieder eine Resource dar, deren URI im LocationHeader nach dem POST zurückgegeben wird. Sie kann gelöscht (DELETE) oder ersetzt (PUT) werden.
  3. Nach DELETE ist eine Resource nicht mehr erhältlich!!!!
  4. Callbacks: bei asynchronen requests kann der Anforderer eine callback-URI mit übergeben, über die dann die Antwort asynchron zurückgegeben werden kann. Die URI gehört dem Server, er sollte aber nicht seinen eigenen Hostnamen reincodieren. (Firewall) Der Vorteil dieser callback-URI wäre, dass nicht nur der Host sondern auch die correlationId gleich enthalten sein kann, über die der Zielrechner den Request finden kann und auch feststellen kann, dass eine Antwort bereits zweimal angekommen ist.
  5. Asynchrone Operationen haben in dem Server, der u.U. eine REST-Schnittstelle bekommen soll ohnehin eine persistente Repräsentation in Form von Jobs. Die erzeugte URI für Aktionen kann also ohne weiteres diese job-Id enthalten und damit immer wieder gefunden werden.
  6. Wenn eine Aktion mehrere Ressourcen betrifft stört das nicht, weil in der zurückgegebenen LocationURI die Resource an der die Aktion gestartet wurde, ohnehin nicht enthalten sein muss.
Im Allgemeinen war mir schon ein bisschen peinlich, dass ich das Dokument, das G. geschrieben hat, nicht vor dem Termin durchgearbeitet hatte. Einige seiner Hinweise hätte er sich dann sparen können. Andererseits hat es mir natürlich sehr geholfen auf diese Weise direkt frontal seine Überlegungen dazu mitzubekommen. Das war für mich viel besser, als mir da ein Richtliniendokument geholfen hätte.
Außerdem machte er mir nicht den Eindruck, als ob es ihm sehr unangenehm wäre, uns bei unseren Überlegungen zu helfen. Er war sehr hilfsbereit. Er hätte auch mit dem Hinweis auf das Terminende, das ganze pünktlich abbrechen können. So haben wir uns eine halbe Stunde länger unterhalten und am Ende habe ich das Gespräch dann beendet.

Keine Kommentare:

Kommentar veröffentlichen