Überarbeitung des Antwortverhaltens bzgl. Exceptions/Fehlermeldungen

[ChrisMalewski]

• Besonders vor dem Hintergrund der Sicherheit und Autorisierung, was wird zurückgeben?
• Welche Fehlercodes?
• Konsistent über alle Endpunkte

[matthesrieke]

TODO:

• Überprüfen im Quellcode
• WV prüft, ob fehlerhaftes Beispiel vorhanden
• Dokumentation entsprechend erweitern (in allgemeiner API-Beschreibung)

[ChrisMalewski]

• Konsistenz zwischen Doku und Endpunkten noch nicht gegeben
• Konsistenz über alle Endpunkte noch nicht gegeben
• Fehlercodes sind noch zu definieren
  --> Weiterbearbeitung im nächsten Meilenstein

Unzulässige Angaben (Nutzer 25991 nicht existent) werden nicht sauber abgefangen

• http://192.168.101.105/eventing-rest-api/v1/users/25991
  o Liefert http 200 und null als JSON Object
  o Soll 400 oder 418 liefern (weitere Diskussion und Verschiebung des Issues auf den nächsten Meilenstein)

Folgender Endpunkt liefert gewünschtes Verhalten

• http://192.168.101.105/eventing-rest-api/v1/subscriptions/29292
  o Liefert 400 und ein Fehlerobjekt
  o Aber inkonsistent zu oben und zur Doku.

Zugriff auf Subscriptions einer Gruppe, in die ich nicht reinschauen darf, da ich kein Mitglied und kein Superadmin bin:

• http://192.168.101.105/eventing-rest-api/v1/subscriptions?groups=57601
  o Liefert http 200 und leere Liste und die Information, dass es total 2 Subscriptions gibt
  o Soll 400 oder 418 liefern (weitere Diskussion und Verschiebung des Issues auf den nächsten Meilenstein)

[ChrisMalewski]

Bei Einzelressourcen und Listen (z.B. notification/:id/subscriptions), für die ein Nutzer keine Berechtigung hat oder die nicht exisitieren --> 404 (wie github)
Bei Filterabfragen mit Filterparametern, für die der Nutzer keine Rechte hat oder nicht existieren leere Liste zurückgeben mit total: 0 und HTTP Code 200.
Exception Handling in der Doku beschreiben.