Parametro API per "includere" risolvendo gli ID sugli oggetti

0

Ho un repository NoSQL con due tabelle, Foo e Bar. Ogni Foo ha alcuni metadati e un elenco di ID della barra. Ogni barra ha alcuni metadati.

Sto scrivendo l'API per il recupero di un Foo e vorrei fornire la possibilità di specificare se il Foo restituito contiene o gli ID Bar relativi o gli oggetti Bar correlati.

Ad esempio, uno potrebbe ottenere /foo/foo-id-1?resolve=false e ricevere la risposta

{
  "id": "foo-id-1",
  "metadata": {...},
  "bars": ["bar-id-1", "bar-id-2", ...]
}

Verso GET /foo/foo-id-1?resolve=true e ricezione

{
  "id": "foo-id-1",
  "metadata": {...},
  "bars": [
    {
      "bar-id-1",
      "metadata": {}
    },
    {
      "bar-id-2",
      "metadata": {}
    }, ...
  ]
}

Mi piacerebbe farlo perché

  1. Nel caso in cui il client abbia bisogno solo dei metadati Foo e non dei metadati della Barra, posso salvare una chiamata al repository per recuperare i metadati della Barra.
  2. Nel caso in cui il client abbia bisogno dei metadati della Barra inclusi in Foo, posso salvare il client effettuando una chiamata risolvendo gli ID Bar agli oggetti.

Le mie domande sono

  1. Quale dovrebbe essere il nome del parametro che fornisce questa capacità? L'ho chiamato "risoluzione" ma c'è qualcosa di meglio (forse "proiezione") o uno standard?
  2. Il parametro deve essere una bandiera, come ho suggerito nell'esempio sopra, o una stringa nel caso in cui vengano aggiunti più bambini Foo? Ad esempio, /foo/foo-id-1?resolve=bars,bazs .
  3. Va bene avere un endpoint (GET su /foo:id ) che restituisce due diversi schemi di dati? Cioè, nel primo caso lo schema dei dati contiene bars :: [String] e nel secondo bars :: [Bar]
posta geofflittle 15.10.2017 - 00:12
fonte

1 risposta

3
  1. In genere chiamiamo riempire un oggetto "vuoto" con dati "idratazione". In questa linea di pensiero, potresti voler avere il tuo parametro "hydrate = 1" o "hydrateRelated = foo, bar".

  2. Una bandiera è più semplice, ma più limitata. Una stringa aumenta la complessità su entrambi i lati dell'API, ma offre maggiore flessibilità. Questo è un compromesso di ingegneria, e dovrai decidere da solo quale dei due ha un senso nel tuo caso. Non esiste una risposta corretta per questo tipo di problema in generale.

  3. Puoi avere oggetti "disidratati" invece di stringhe, e quindi lo schema è logicamente lo stesso (ma i client devono essere in grado di gestire gli oggetti disidratati, che dalla tua domanda sembra essere comunque necessario):

    {   "id": "foo-id-1",   "metadati": {...},   "barre": [     {"id": "bar-id-1"},     {"id": "bar-id-2"},     ...   ] }

risposta data 15.10.2017 - 03:45
fonte

Leggi altre domande sui tag