Tach!
/buildings
/buildings/create
/buildings/storeist das sinnvoll?
Warum nicht? Ohne den Anwendungsfall zu kennen, kann man das nur schlecht einer Sinnhaftigkeitsbewertung unterziehen.
/buildings/{id}
Aha! Logisch?
Da muss nicht unbedingt eine Logik dahinterstecken. Üblicherweise klickt man sich durch eine Website, ohne die URL großartig zu beachten oder ihr eine großartige Bedeutung zuzumessen. Der Aufbau des Pfades spielt also meist keine übermäßige Rolle. Wichtig ist (aus technischer Sicht) im Prinzip nur, dass der Router sie auseinanderhalten kann.
Warum nicht so?
/buildings /buildings/{id|new} /buildings/{id|new}/edit /buildings/{id|new}/store
Ist store denn auf ein einzelnes Element bezogen? Vermutlich hat das nichts mit Speichern zu tun, sondern mit einem Store, in dem mehrere Dinge zu sehen sind.
Der Pfad
/buildings/{id|new}/create
scheint mir dann unnötig./buildings/{id|new}
führt dann sinnvollerweise automatisch zu/buildings/{id|new}/edit
.
Bei einem Create ist die ID in der Regel noch nicht bekannt. Stattdessen new
als Wort zu verwenden macht es nicht besser. Die Kombination von new und edit ergibt auch keinen gesteigerten Sinn.
Meine Vorgehensweise für CRUD
/thing/ für eine Liste
/thing/:id für das Edit-Formular
/thing/add für das Edit-Formular für neue Elemente
Detail-Ansicht ist keine eigenen Seite sondern ein modaler Dialog, und Löschen ist auch nur ein Ajax-Request aus der Listenansicht. Diese beiden brauchen also keinen eigenen Pfad. Anwendungsfall ist hier eine Angular-SPA ohne Ohne-Javascript-Fallback. Gegebenenfalls gibt es weitere Aktionen, die sind dann à la /thing/foo
und /thing/bar
hinzugefügt.
dedlfix.