Rappresentazione di dati aggregati senza risorse con API JSON

Question

Sto lavorando a un'app per la quale stiamo studiando la possibilità di utilizzare jsonapi per descrivere i dati in tutte le risposte API. Funziona piuttosto bene per entità simili a risorse, ma abbiamo qualche problema a trovare un modo per descrivere i dati dei report in modo jsonapi-like.

Con i dati dei report mi riferisco a dati aggregati e calcolati al volo dai dati di base delle risorse che memorizziamo nel nostro database. Ad esempio, immaginiamo di archiviare le informazioni immobiliari, e abbiamo informazioni su case, appartamenti e uffici, ciascuna associata alla posizione, alle dimensioni dell'immobile in piedi quadrati, al tipo di proprietà (se si tratta di una casa, appartamento o ufficio), e ogni altra informazione pertinente su una proprietà. Ora immaginiamo di aver bisogno di un rapporto che riceve ?group_by[]=location&group_by[]=type e vogliamo che la risposta trasmetta informazioni aggregate sull'intersezione di questi due parametri group_by. Quindi, per esempio, riceveremo un oggetto contenente l'area dei piedi quadrati medi di tutte le proprietà in una determinata posizione, raggruppate anche per tipo di proprietà.

Average Property Sizes (in square feet) 
       Houses Apartments Offices 
Manhattan  1234.56  234.56 123.45 
Cape Coral  456.78  654.32 876.54 
Portland  4321.00  987.65 2345.67 

La risorsa simile cosa più possiamo pensare da questi dati è ogni cella, ma dal momento che sono il risultato di un'aggregazione calcolato di dati più di base, non hanno un ID naturale. Abbiamo pensato di distribuirli con un ID calcolato (magari combinando gli ID delle dimensioni con cui sono raggruppati i loro dati, ovvero "house,34" dove house rappresenta un tipo di proprietà e 34 è l'ID della posizione "Manhattan"). Quindi ogni cella avrebbe la relazione con il record di posizione corrispondente, che verrebbe incluso nella sezione included del payload. Ecco un file JSON esempio di come potrebbe apparire come questo:

{ 
    "data": [ 
    { 
     "id": "house,123", 
     "type": "report_items", 
     "attributes": { 
     "property_type": "house", 
     "value": 108.75 
     }, 
     "relationships": { 
     "location": { 
      "data": { 
      "type": "locations", 
      "id": 123 
      } 
     } 
     } 
    }, 
    { 
     "id": "house,124", 
     "type": "report_items", 
     "attributes": { 
     "property_type": "house", 
     "value": 36.0 
     }, 
     "relationships": { 
     "location": { 
      "data": { 
      "type": "locations", 
      "id": 124 
      } 
     } 
     } 
    }, 
    { 
     "id": "house,125", 
     "type": "report_items", 
     "attributes": { 
     "property_type": "house", 
     "value": 1.0 
     }, 
     "relationships": { 
     "location": { 
      "data": { 
      "type": "locations", 
      "id": 125 
      } 
     } 
     } 
    }, 
    { 
     "id": "office,123", 
     "type": "report_items", 
     "attributes": { 
     "property_type": "office", 
     "value": 4.0 
     }, 
     "relationships": { 
     "location": { 
      "data": { 
      "type": "locations", 
      "id": 123 
      } 
     } 
     } 
    }, 
    { 
     "id": "office,124", 
     "type": "report_items", 
     "attributes": { 
     "property_type": "office", 
     "value": 2.0 
     }, 
     "relationships": { 
     "location": { 
      "data": { 
      "type": "locations", 
      "id": 124 
      } 
     } 
     } 
    }, 
    { 
     "id": "apartment,123", 
     "type": "report_items", 
     "attributes": { 
     "property_type": "apartment", 
     "value": 2.0 
     }, 
     "relationships": { 
     "location": { 
      "data": { 
      "type": "locations", 
      "id": 123 
      } 
     } 
     } 
    }, 
    { 
     "id": "apartment,125", 
     "type": "report_items", 
     "attributes": { 
     "property_type": "apartment", 
     "value": 4.5 
     }, 
     "relationships": { 
     "location": { 
      "data": { 
      "type": "locations", 
      "id": 125 
      } 
     } 
     } 
    }, 
    { 
     "id": "apartment,124", 
     "type": "report_items", 
     "attributes": { 
     "property_type": "apartment", 
     "value": 2.0 
     }, 
     "relationships": { 
     "location": { 
      "data": { 
      "type": "locations", 
      "id": 124 
      } 
     } 
     } 
    } 
    ], 
    "included": [ 
    { 
     "type": "locations", 
     "id": "123", 
     "attributes": { 
     "name": "Manhattan" 
     } 
    }, 
    { 
     "type": "locations", 
     "id": "124", 
     "attributes": { 
     "name": "Cape Coral" 
     } 
    }, 
    { 
     "type": "locations", 
     "id": "125", 
     "attributes": { 
     "name": "Portland" 
     } 
    } 
    ] 
} 

La mia domanda è: è questo un modo corretto di rappresentare questo tipo di dati in jsonapi? Jsonapi è adatto e/o raccomandato per i dati che non si collegano direttamente alle risorse? Farei meglio a rappresentare questi dati in json personalizzato? So che non tutte queste domande hanno probabilmente una risposta certa, ma forse c'è già qualche esperienza in merito a come affrontare scenari simili, pro e contro di tentare di inserire questo tipo di dati su jsonapi, ecc. Qualsiasi commento e aiuto è molto molto apprezzato. Grazie.

PS: L'ho postato anche dopo aver scavato nel forum e su Internet, e questi sono gli unici due collegamenti che ho trovato che parlano di qualcosa che assomiglia a quello che sto cercando di scoprire, e li includo qui per riferimenti così: 1.- http://discuss.jsonapi.org/t/composite-id-inside-the-resource-object/367/13 2.- http://discuss.jsonapi.org/t/extension-for-chart-graph-data/408

Answer 1

La risposta generale è quella di considerare che i dati è abbastanza significativo da giustificare un'identità su entrambi i lati del vostro API. Con questo intendo decidere quali cose o vuoi fare riferimento più tardi o rappresentare con le relazioni. L'API JSON consente di definire tali elementi come risorse e consente di combinare le risorse con un JSON più generico per i dati opachi.

Ad esempio, forse reports e le opzioni e i filtri che hai utilizzato per crearli meritano di essere tracciati in modo che un cliente possa richiedere una nuova visualizzazione dello stesso rapporto dal suo id. Forse vuoi eseguire il polling del tuo server per vedere quali report vengono creati.

Sul lato client, è possibile presentare collegamenti dalle risorse property_type a ulteriori informazioni su tali tipi di proprietà.

O forse i risultati in un report sono rappresentati meglio come un BLOB di JSON all'interno di una risorsa. attributes e meta possono contenere qualsiasi tipo di valori JSON.

Nel vostro caso particolare, la vostra risorsa primaria potrebbe essere di tipo reports, o un array di report_items, o forse anche una serie di property_summaries con le relazioni a property_types e locations.

Se si scelgono più tipi generici di risorse, è possibile generalizzare il processo di segnalazione, ma non è possibile acquisire il significato dei dati.

Se si scelgono risorse molto specifiche per i report, è necessario personalizzare davvero ogni tipo di report, ma sarà possibile stabilire connessioni significative tra le risorse sul client.