Talk:stoney core: REST API

Fragen / Inkonsistenzen

• Relations (queries/scoping): Haben wir nicht getestet!
  • /v1/resellers/4000001/customers -> collection resource (all customers of reseller with uid=4000001)
  • /v1/resellers/4000001/customers/4000002 -> resource (the customer with uid=4000002 of reseller with uid=4000001)
  • /v1/customers?belongsToResellerUID=4000001 -> collection resource (all customers of reseller with uid=4000001)
  • /v1/customers/4000002 -> resource (the customer with uid=4000002 of reseller with uid=4000001)

• Wollen wir zukünftig statt zuwenig Berechtigungen immer einen leeren JSON Wert zurück geben? Ähnlich wie bei der Suche, wenn sie keine Ergebnisse findet.
  • Sonst konkret definieren, was zurück kommen muss.
  • Bei einer Collection: ja. (tun wir das nicht bereits?). Bei einem Element muss ein Fehlerwert zurückgegeben werden. Ich hätte hier gerne jedoch 404 Not Found anstatt Permission Denied. --Tiziano (talk) 12:37, 5 January 2015 (CET)
  • Das ist bereits definiert 403 (Forbidden) mit einem JSON error object welches weitere Details liefert. --Chrigu (talk) 16:10, 8 January 2015 (CET)
  • 403 ist OK

• Actions
  • Den neuen HTTP Status Code "202 Accepted" einführen?
    • The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.
    • Eine Location für die Status-Abfrage ist nötig! In Form einer Job-ID oder ähnlichem.
    • Ja, aber dafür benötigen wir das Framework dahinter. Im Moment würde ich das ignorieren und so tun als wäre die Aktion sofort und erfolgreich ausgeführt worden. --Tiziano (talk) 12:37, 5 January 2015 (CET)
      • Finde ich gefährlich, der Client macht weiter obschon es das Objekt noch gar nicht gibt/geben wird (im Fehlerfall) --Chrigu (talk) 16:20, 8 January 2015 (CET)
      • die Alternative dazu ist dass wir uns bald für eine Messaging Middleware Lösung für Puppet/MCollective entscheiden und darauf aufbauend einen Job Server hochbringen. Das hiesse vermutlich: RabbitMQ/RabbitMQ Symfony Bundle und Celery --Tiziano (talk) 18:03, 7 January 2015 (CET)
  • 202 Accepted ist gut, es muss jedoch noch eine neuer Paramter wie zum Beispiel "provisioningState" oder "actionState" auf dem Location Ziel-Element eingeführt werden.

• Passwörter
  • Bei Update (PUT) haben wir nirgendwo klar definiert, dass das Passwort nicht nötig ist.
  • Es ist nirgendwo definiert, wie ein Passwort aussehen darf:
    • Minimale Länge?
    • Gross-/Kleinschreibung?
    • Sonderzeichen und/oder Zahlen?
  • Fände es gut, wenn wir dies zentral vorgeben.
    • Wir können minimale Vorgaben dokumentieren, hängt aber ggf vom Authentication Backend ab. Allzuviel Zeit würde hier nicht investieren. --Tiziano (talk) 12:37, 5 January 2015 (CET)
  • Eventuell lassen wir die Vorgaben via API abfragen? In diesem Falle müsste es ins stoney-core Modul gehören?
    • Zu aufwändig für den Nutzen. --Tiziano (talk) 12:37, 5 January 2015 (CET)
  • Minimale Anforderungen definieren