Mappatura delle risorse in un URL Ruby on Rails (API RESTful)

Question

Ho un po 'di difficoltà a trovare la risposta giusta, quindi solleciterò il mio problema qui. Sto lavorando su un'API RESTFul. Naturalmente, ho molte risorse, alcune delle quali consistono in relazioni da genitori a figli, alcune delle quali sono risorse autonome. Dove sto avendo un po 'di difficoltà è capire come rendere le cose più facili per le persone che costruiranno clienti contro la mia API.

La situazione è questa. Ipoteticamente ho una risorsa 'Street'. Ogni strada ha più case. So Street: has_many to Homes and Homes: appartiene alla strada. Se un utente desidera richiedere un HTTP GET su una risorsa di casa specifica, il seguente dovrebbe funzionare:

http://mymap/streets/5/homes/10

che consente all'utente di ottenere informazioni per una casa con l'id 10. dritto in avanti. La mia domanda è, sto rompendo le regole del libro, dando all'utente l'accesso a:

http://mymap/homes/10

Tecnicamente esiste tale risorsa a casa da sola, senza la strada. Rende senso che esiste come una propria entità senza una strada incapsulante, anche se la logica aziendale dice diversamente.

Qual è il modo migliore per gestire questo?

MODIFICA! Nello spirito di diventare un buon cittadino di StackOverflow, sono tornato con un blocco di codice supportato su come implementarli sopra.

map.resources :streets, 
       :has_many => :homes 
       :shallow => true 

Questo creerà entrambi i tipi di percorsi che stavo cercando.

Answer 1

Se i record di casa possono appartenere solo a una strada, la relazione non verrà confusa quando si esamina una casa individualmente. Sarai comunque in grado di eseguire il back-track sul record Street associato per qualsiasi motivo.

È in situazioni in cui si ha una relazione molti-a-molti che la nidificazione della struttura REST può metterti nei guai. Se un determinato record ha senso solo in un particolare contesto, e tu rimuovi quel contesto, ovviamente c'è confusione.

Penso che nel tuo caso particolare potresti non aver bisogno di implementare entrambi gli approcci, ma preferibilmente andare con l'approccio "più piatto" che riduce la complessità dell'URL.

Answer 2

No, è così che i percorsi poco profondi funzionano e vengono utilizzati molto.

Answer 3

Mi piace molto l'approccio this. Consiglio di leggerlo. In breve, questo articolo dice che non dovresti annidare le tue risorse più di 1 livello. E se è possibile che la risorsa nidificata possa essere ridotta, allora fallo.

In una delle mie applicazioni ho davvero incasinato le cose con le risorse annidate. Vado anche a 3 o 4 profondità e diventa un incubo ...

L'annidamento è davvero bello se rende le cose più semplici. Altrimenti, lascia perdere!