KIF495:FITNESS (vormals: NAPfifioges) Hackathon

Aus KIF
Die druckbare Version wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

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