Gestire relazioni molte a molte usando Uri restful

3

Sto avendo confusione durante la scelta di una relazione tra database e URI restful per l'applicazione che sto sviluppando.

Sto facendo una semplice applicazione di libreria con i seguenti requisiti.

  1. Il libro può appartenere a molte categorie, ad esempio il libro di fisica appartiene alla categoria di libri di testo e scienze. Possiamo dire che il libro ha molte categorie / etichette / tag.
  2. Visualizzazione di libri in una categoria.
  3. Visualizzazione di tutte le categorie di un libro.
  4. Ricerca del libro utilizzando categorie o informazioni sui libri.
  5. Prenota operazioni CRUD
  6. Etichetta le operazioni CRUD

Considerando tutti questi requisiti, scelgo la relazione ManyToMany tra libri ed etichette. L'ho implementato usando Hibernate Framework. Ora, quando si trattava di progettare i servizi restful per questo motivo, è diventato molto confuso. Mi fa anche una scelta di relazioni con la tabella delle domande.

Ancora uri riposati.

/ libri

/ libri / {BookID}

/ etichette

/ etichette / {labelid}

Ma quando voglio ottenere un elenco di etichette rispetto a un libro o un elenco di libri contro un'etichetta. Come mapparli usando URI restful. Posso pensare a questo

/ libro / {} BookID / etichette

Ma considerando questo, come mappare l'ottenimento di un elenco di libri rispetto a un'etichetta

Voglio sapere se la mia scelta del rapporto con il tavolo è giusta e se sì, come progettare un uri riposante contro di esso. E se no, per favore correggimi e fai luce su questo scenario. Grazie

    
posta Saif ullah Minhas 05.08.2015 - 04:42
fonte

1 risposta

3

Per quanto riguarda il tavolo, se un libro può avere molte etichette e un'etichetta di molti libri (sembra abbastanza ragionevole), allora è una relazione molte a molte.

In caso di REST la relazione molti a molti è in realtà un po 'confusa dal momento che parliamo di risorse e con l'URI che è un identificatore unico sembra strano poter accedere a uno stesso risorsa da due direzioni.

Forse il modo migliore è vedere una risorsa non solo come una cosa semplice (libro, etichetta) ma anche come un insieme specifico di cose (libri, etichette di un libro). Spesso si hanno risorse nidificate e la maggior parte è solo una variante in cui due modi diversi per visualizzare questi insiemi hanno senso (presupponendo che gli utenti vorranno accedere in entrambe le varianti, il che sembra probabile per il proprio caso d'uso).

Quindi in effetti avresti due modi per accedere a questo:

/book/{book_id}/labels

e

/label/{label_id}/books

Molto probabilmente avrai approcci simili per altre risorse come gli autori (l'autore può aver scritto molti libri e abbastanza spesso molti autori lavorano insieme su un singolo libro) o persino gli editori. Anche le categorie presumerei fossero molte per molti.

Quando sombody seleziona una singola etichetta dagli URI superiori (/ book / {book_id} / labels) puoi ovviamente tornare all'URI dell'etichetta normale (/ label / label_id) invece di costruire percorsi extra lunghi come (/ book / {} libro_id / label / {} label_id).

Quindi mantieni le rotte più basse possibile, evita di annidarle troppo in profondità. Ma nulla vieta di avere opinioni diverse su elenchi di cose simili.

    
risposta data 05.08.2015 - 09:38
fonte

Leggi altre domande sui tag