Ich arbeite an einer App, für die wir die Möglichkeit untersuchen, jsonapi zu verwenden, um die Daten in allen API-Antworten zu beschreiben. Es funktioniert ziemlich gut für ressourcenähnliche Entitäten, aber wir haben einige Schwierigkeiten damit, Berichtsdaten auf eine Art jsonapi-ähnlich zu beschreiben.Darstellen von nicht-aggregierten Daten mit JSON API
Mit Berichtsdaten beziehe ich mich auf Daten, die aggregiert und von den ressourcenähnlichen Basisdaten, die wir in unserer Datenbank speichern, berechnet werden. Stellen Sie sich zum Beispiel vor, wir speichern Immobilieninformationen, und wir haben Informationen über Häuser, Wohnungen und Büroflächen, die jeweils mit dem Standort, der Größe der Immobilie in Quadratfuß, der Art der Immobilie (ob Haus, Wohnung oder Büro) verbunden sind. und alle anderen relevanten Informationen über eine Immobilie. Nun stellen Sie sich vor, wir benötigen einen Bericht, der ?group_by[]=location&group_by[]=type empfängt und wir möchten, dass die Antwort aggregierte Informationen über die Schnittmenge dieser beiden group_by Parameter übermittelt. So würden wir beispielsweise ein Objekt erhalten, das die durchschnittliche Quadratfußfläche aller Eigenschaften an einem bestimmten Ort enthält, die ebenfalls nach Art der Eigenschaft gruppiert sind.
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
Die ressourcen wie, was wir von diesen Daten sind jede Zelle denken können, aber da sie das Ergebnis einer berechneten Aggregation von mehr Basisdaten sind, sie keine natürliche ID haben. Wir haben darüber nachgedacht, sie auch mit einer berechneten ID zu versehen (vielleicht die IDs der Dimensionen zu kombinieren, nach denen ihre Daten gruppiert sind, dh "house,34", wobei house einen Eigenschaftstyp darstellt, und 34 ist die ID des Standorts "Manhattan"). Dann würde jede Zelle die Beziehung zu dem entsprechenden Ortsdatensatz haben, der in dem included Abschnitt der Nutzlast enthalten wäre. Hier ist ein Beispiel JSON-Datei, wie würde dies wie folgt aussehen:
{
"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"
}
}
]
}
Meine Frage ist: ist dies eine richtige Art und Weise, diese Art von Daten in jsonapi zu vertreten? Ist jsonapi geeignet und/oder empfohlen für Daten, die nicht direkt Ressourcen zuordnen? Wäre es besser, diese Daten in benutzerdefinierten JSON darzustellen? Ich weiß, dass keine dieser Fragen wahrscheinlich eine definitive Antwort haben, aber vielleicht gibt es bereits Erfahrung, wie man ähnliche Szenarien angehen kann, Vor- und Nachteile, um zu versuchen, diese Art von Daten auf jsonapi usw. anzupassen. Kommentare und Hilfe sind sehr sehr geschätzt. Vielen Dank.
PS: Ich postete dies auch nach ein paar Ausgrabungen im Forum und im Internet, und das sind die einzigen zwei Links, die ich gefunden habe, die über etwas sprechen, was ich versuche herauszufinden, und ich schließe sie ein hier für Verweise sowie: 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
Ich frage nicht nach einer spezifischen Lösung für diesen speziellen Fall, aber für einige Informationen bezüglich der Möglichkeit, JSON API für diese Art von nicht-einfallsreichen Daten zu verwenden. Ist es empfehlenswert? Sollte ich zusätzliche Anstrengungen unternehmen, um meine Daten an JSON API anzupassen? Oder vielleicht ist JSON API speziell für die Verwendung mit ressourcenähnlichen Daten konzipiert? – Ernesto