Oggetti nidificati in REST

Question

Oggetti nidificati in REST

Naviga le tue risposte

#1 da (3 voti)

6

Ho un insieme semplice di risorse, non più di 10 tipi, con alcune relazioni uno-a-molti. Ad esempio

Un ordine ha molte voci
Una voce ha molti commenti
Una macchina può avere più voci associate
Un materiale può avere più ordini associati

Tutti gli oggetti del modello sono identificati da un'unica chiave primaria

Comunico utilizzando le chiamate HTTP REST. Come dovrebbero essere modellati gli oggetti?

Opzione 1: Nidificazione di oggetti

Le relazioni possono risultare in oggetti nidificati:

entry{
  PK: '_',
  prop1: '_',
  prop2: '_',
  machine:{
    PK: '_',
    prop3: '_'
  },
  order: {
    PK: '_',
    material: {
      PK: '_',
      prop4: '_'
    }
  }
}

E allo stesso modo per gli altri oggetti

Opzione 2: riferimento di PK

Questo approccio "appiattisce" gli oggetti:

entry{
  PK: '_',
  prop1: '_',
  prop2: '_',
  machinePK: '_',
  orderPK: '_'
}

Qual è l'approccio migliore? ovviamente entrambi hanno chiari vantaggi e svantaggi. Un approccio ibrido è una soluzione praticabile? In tal caso, quale criterio dovrei seguire per scegliere tra oggetti "piatti" o "nidificati"? Potrebbe forse dipendere dalla tecnologia che uso per implementarlo (cambiare il modello a causa delle tecnologie puzza di cattiva pratica ...)?

Per dare un po 'di contesto, sto usando ASP.NET WebApi 2 per il backend e AngularJS in Typescript per il frontend

design rest modeling

posta Giacomo Tagliabue 24.06.2014 - 23:20

fonte

1 risposta

Leggi altre domande sui tag design rest modeling

Strategie per gestire più client in grado di modificare contemporaneamente gli stessi dati Entity Framework 6 è abbastanza agnostico con diverse piattaforme SQL Server e SO?

score 3 · Accepted Answer

Dipende dall'esperienza che si desidera avere per il programmatore e dalla complessità e dalle prestazioni della tua applicazione.

Se il singolo oggetto è di grandi dimensioni e il consumatore dell'API non ha bisogno di tutti i dati in anticipo, è possibile suddividerlo in più blocchi e richiamarli se desiderano un oggetto correlato.
Con oggetti più grandi, l'elaborazione e le prestazioni sul server potrebbero aumentare, il che potrebbe essere di per sé un problema, quindi dovresti tenerlo abbassato.
D'altra parte, se il tuo oggetto è veramente "incompleto" senza gli oggetti secondari, allora potresti considerare di mandarli in una volta sola.

Non penso che PK sia necessariamente un termine standard che viene compreso da persone diverse da quelle che si occupano di database. Per le API REST, i nomi più adatti potrebbero essere EntryId, OrderId, MachineId ecc. O più genericamente Id e ObjectId, ecc.

Inoltre, non è sempre necessario inviare ObjectId per gli elementi nidificati, l'API stessa rivelerà le relazioni (che è il tipo di scopo di riposo), e quindi, dal tuo esempio, la voce vorrebbe questo:

entry{
  Id: "42",
  prop1: '_',
  prop2: '_',
}

Se qualcuno volesse trovare tutti gli ordini per una voce, emetterà qualcosa del genere:

https://www.example.com/entries/42/orders

Ciò otterrà tutti gli ordini per la voce # 42 (con paging ecc. se necessario).

Potresti vedere questa pagina per le best practice per URL REST e questa pagina per i collegamenti ad altre best practice sulle API Rest. Potresti anche voler dare un'occhiata a OData dal momento che si occupa principalmente di dati e si basa sulle API REST. Ricordati di convalidare ovviamente e ottenere altre opinioni.