Angulare ui-Router-Statusnamen für verschachtelte REST-Ressourcen

Question

Ich entwerfe derzeit eine neue API und eine Webanwendung, die die API verwendet.

Zum Beispiel nehme ich die folgenden REST-Ressourcen haben (eine feder Boot-Micro verwenden):

GET /orders   // get all orders 
POST /orders   // create an order 
GET /orders/1   // get order with id 1 
PUT /orders/1   // update order with id 1 

GET /orders/1/items // get all order items 
POST /orders/1/items // create an order item 
GET /orders/1/items/2 // get the order item with id 2 of order with id 1 
PUT /orders/1/items/2 // update order item with id 2 of order with id 1 

Ich denke, dies ist eine sehr häufige Nutzung. In meiner Anwendung sind Ressourcen viel mehr verschachtelt.

Ich benutze eckig mit dem UI-Router und ich möchte Staaten/URLs für die entsprechenden Formulare/Ansichten definieren, die so nah wie möglich an die REST-API sind. Da es nicht möglich ist, dieselbe URL für GET, POST, PUT zu verwenden, möchte ich wissen, welche Standards (Best Practices) für die Definition dieser Zustände gelten.

Fast alle Texte, Tutorials usw. verwendet die folgenden URLs/Zustände für die CRUD Methoden:

/#/orders/    // state: orders 
/#/orders/create  // state: orders.create 
/#/orders/1/show  // state: orders.show 
/#/orders/1/edit  // state: orders.edit 

Dieser recht geradlinig ist. Aber niemand diskutiert, wie verschachtelte Ressourcen entworfen werden. Daher wäre es interessant, wie Sie mit der verschachtelten Artikel-Ressource umgehen würden.

Normalerweise möchte ich eine verschachtelte Ansicht mit einem Controller haben, um die Elemente anzuzeigen, so dass die Elemente ein Kind-Status des Status orders.show ist.

Daher Wenn ich das gleiche Schema verwenden würde, wie sie in den Büchern/tutorials vorgeschlagen, wäre es in die folgenden URLs führen:

/#/orders/1/show/items   // state: orders.show.items 
/#/orders/1/show/items/create // state: orders.show.items.create 
/#/orders/1/show/items/2/show // state: orders.show.items.show 
/#/orders/1/show/items/2/edit // state: orders.show.items.edit 

Aber: Diese URLs irgendwie nicht richtig aussehen. Also, welche Erfahrungen und Empfehlungen gibt es? Oder welche Vorschläge gibt es, um eine saubere URL und damit eine saubere Anwendungsstruktur zu erhalten?

Answer 1

Auch ich suche eine Lösung für ein ähnliches Problem. Das ist das Beste, was ich bisher bekommen habe:

contacts (abstract, url: '/contacts') 
contacts.list (url: '/', resolve: { contacts }) 
contacts.new (url: '/new') 

contacts.one (abstract, url: '/contacts/:id', resolve: { contact }) 
contacts.one.show (url: '')       # => /contacts/1 
contacts.one.edit (url: '/edit')     # => /contacts/1/edit 
contacts.one.addresses (abstract, url: '/addresses') 
contacts.one.addresses.list (url: '', resolve: { user.addresses }) 
contacts.one.addresses.new (url: '/new')   # => /contacts/1/addresses/new 

contacts.one.addresses.one (abstract, url: '/:id', resolve: { address }) 
contacts.one.addresses.one.show (url: '')   # => /contacts/1/addresses/1 
contacts.one.addresses.one.edit (url: '/edit')  # => /contacts/1/addresses/1/edit