Guido Laures wrote:
Irgendwie erscheint es mir inkonsequent, wenn manchmal POST per HTML Form und manchmal mittels JSON Objekt erfolgt. Das sollte doch irgendwie einheitlich sein, oder? Ich schneide die Ressourcen recht feingranular und sie können geschachtelt
Ja, da hast du Recht. Du scheintst dir ja auch schon einige Gedanken gemacht zu haben. Wenn ich dir bzgl. der Use-Cases/Ressourcen-Design irgendwie helfen kann oder zumindest meine Client-Perspektive einbringen kann, sag bescheid. Ich habe bei der iPhone-App jetzt erstmal mit den Tipps angefangen (im ersten Milestone nur read-only). Ich schicke dir mal das Test-JSON, mit dem ich z.Zt. hier arbeite, per Mail damit du siehst welche Properties ich so brauche.
Guido Laures wrote:
Es handelt sich bei der Authentifizierung nicht um die JSESSIONID, da diese ja bewirkt, dass ein Client State auf dem Server entsteht. Böse, böse. Deshalb wird das Authtoken als Ressource betrachtet, die man mittels Übergabe der Credentials per HTML-Form erhält. In dem Token ist auch die Gültigkeitsdauer (6h) eincodiert. Das Token kommt sowohl als JSON Objekt als auch als Cookie zurück. Sollte übrigens schon klappen: /rest/authtoken, Parameter login und password.
Klingt sehr schlüssig und funktioniert auch super. Per se würde ich die Java Session allerdings nicht als böse betrachten. Kommt schließlich darauf an, ob du Clinet/Application-State in der Session speicherst oder nicht. Aber das Token als Ressource zu haben klingt vernünftiger und gefällt mir gut
Und ist sicher auch sinnvoll, wenn du mal skalieren und nicht gleich die JVM mit Terracotta oder so clustern willst.
Freue mich auf die API
Gruß und noch frohe Rest-Ostern.
Daniel