KIF495:FITNESS (vormals: NAPfifioges) Hackathon

Datenbank-Schema bzw. direkt auf GitLab (für Leute mit Zugang). Und weitere Notizen auf GitLab von FITNESS

Vorschlag für API-Entwürfe, zumindest im "fortgeschritteren" Stadium: https://raml.org/ und https://json-schema.org/ (draft 7?) und OpenAPI

API-Diskussion

• Prämissen
  • schon mal über Einzelfälle Gedanken machen
  • konkreter Entwurf erst einmal minimal

• Trennung Präsentation/Statistik-Seite
  • grafische Präsi
  • alles auf Statistik
  • → wählbarer Detailgrad für API-Endpoints?

• High-Level-API-Idee:
  • `/studentAssociation`
    • GET → ALLE
    • `/$id` → einzelne
      • POST → neue, PUT → ändern
      • GET → (`/overview`?) grobe übersicht (z.B. für slides)
        • Name, Logo, URL, Hochschule, Bundesland, Gruppenfoto?, ?
      • GET `/stats` → $huge pile of data
        • statistiken (evtl. mit Range-Parameter für von-bis?)
  • `/federalState`
    • GET `/$id` → ein Bundesland
      • GET `/$id?includeChildren=$level` → inkl. Subtrees (`$level` aus [university, studentAssociation] bis zu dem Teilelemente eingebunden werden)

• Fall: "globale Revisionen"
  • POST `/revisions` → neue revision
    • body: geschachtelte Struktur mit allen zu setzenden Eigenschaften
  • pro: globale revisionen lassen sich einfacher "enttrollen", nur wenige überhaupt schreibende Endpoints
  • con: zusmmenkratzen der Änderungen im Client und nachher aufdröseln im Backend wird nervig, die Aufteilung in "ok by default" vs. "Freischaltung nötig" wird schwierig

Alternativ:

• • POST `/revisions` → gibt revisions-ID + token
    • POST `/resource/$revId` → ordnet zu
  • pro: weniger geschachtelt
  • con: Änderung muss "finalisiert" werden?

• Fall: "lokale Revisionen" [VORLÄUFIG GEWÄHLT]
  • POST `/resource`
    • body: nur die für die Resource relevanten Daten
  • pro: einfach in der Umsetzung, klare REST-Resourcen-Semantik
  • con: mehrere Anfragen, wenn mehrere Datenpunkte geändert werden sollen (muss von Client-Software dann sinnvoll getan werden)
    • mehrere Anfragen lassen sich durch UI-Design (blockweise editieren) gut kaschieren und führen zu weniger Zeit für Race-Conditions

Alternativ:

• • POST `/update` → erzeugt mehrere Revisionen
    • body: geschachtelte Änderungs-Daten

   {
     "federalState": { // braucht Freigabe
       "name": "unser neues Bundesland"
     },
     "university": { // braucht evtl. Freigabe, weil Änderung vom Bundesland
       "id": "123456-abcdef-7899"
       "name": "neuer Name der Uni",
       "federalState": "$new",
       "url": null // hat jetzt keine mehr → "löschen" von nullable Typen
     },
     "studentAssociation": {
       "name": "unsere neue Fachschaft",
       "univerisity": "123456-abcdef-7899",
       "logo": "https://example.com"
     },
     "attendance": {
       "event": "50.5",
       "studentAssociation": "$new", // irgendein Platzhalter für "das von oben"
       "attending": true
     },
   }

———————————————————————————————————————

Ist-Zustand bei Ende des AKs

• Angefangener Prototyp: https://gitlab.fachschaften.org/kif/fitness/prototype.git
• zwischen KIFs weiter per Matrix in Kontakt bleiben