Difference between revisions of "Talk:stoney core: REST API"

From stoney cloud
Jump to: navigation, search
(→‎Fragen / Inkonsistenzen)
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
= Fragen / Inkonsistenzen =
 
= Fragen / Inkonsistenzen =
−
 
−
* Wir haben im Header eine Location. Im Body manchmal ja, manchmal nein.
 
−
** Gehört die Location in die Body Response rein? Falls ja:
 
−
*** Location müsste bei Update auch nicht hochgeschrieben werden?
 
−
 
−
* Update
 
−
** Statt leerem Body wäre hier eine Antwort logisch, wie bei der Kreierung.
 
−
 
−
* http://wiki.stoney-cloud.org/wiki/stoney_core:_People_Resource_-_REST_API#People_collection_retrieval_response_message
 
−
** Location ist definiert, jedoch im Example nicht drin und entsprechend auch nicht umgesetzt.
 
−
** Location würde in diesem Falle dem "current" entsprechen (zwischen "pre" und "next").
 
−
 
−
* Caching Controls: Manchmal kommt "Cache-Control: no-cache" zurück, manchmal "Cache-Control: none, private".
 
−
 
−
* the service must recognize ETag, Last-Modified and Cache-Control: none provided by the client and act accordingly.
 
−
** Machen wir überhaupt etwas mit dem "Cache-Control: none"? Müsste dies nicht eh der Default-Wert sein?
 
−
 
−
* Mit belongsToResellerId und belongsToCustomerId sind wir inkonsequent. Manchmal haben wir eine belongsToResellerId, manchmal nicht.
 
  
 
* Relations (queries/scoping): Haben wir nicht getestet!
 
* Relations (queries/scoping): Haben wir nicht getestet!
Line 27: Line 9:
 
* 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.
 
* 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.
 
** 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. --[[User:Tiziano|Tiziano]] ([[User talk:Tiziano|talk]]) 12:37, 5 January 2015 (CET)
−
* Meiner Meinung nach müsste gemäss Spezifikation (On success (200) an empty response message body will be returned, otherwise ...) bei einer Löschung ein leerer JSON String und nicht "{ "success": 1 }  zurück gegeben werden.
+
** Das ist bereits definiert [[stoney_core:_REST_API#Error_codes_and_responses|403 (Forbidden) mit einem JSON error object]] welches weitere Details liefert. --[[User:Chrigu|Chrigu]] ([[User talk:Chrigu|talk]]) 16:10, 8 January 2015 (CET)
−
** http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#2xx_Success
+
** '''403 ist OK'''
−
** Wir müssten eigentlich "204 No Content" erhalten:
+
−
*** The server successfully processed the request, but is not returning any content. Usually used as a response to a successful delete request.
+
−
** Bei "200 OK" käme sonst "In a POST request the response will contain an entity describing or containing the result of the action." zurück.
+
−
*** In diesem Falle würde ich eher "{ "Deletion successful": 1 } erwarten.
+
−
 
+
−
* 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.
+
  
 
* Passwörter
 
* Passwörter
Line 47: Line 20:
 
*** Sonderzeichen und/oder Zahlen?
 
*** Sonderzeichen und/oder Zahlen?
 
** Fände es gut, wenn wir dies zentral vorgeben.
 
** 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. --[[User:Tiziano|Tiziano]] ([[User talk: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?
 
** 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. --[[User:Tiziano|Tiziano]] ([[User talk:Tiziano|talk]]) 12:37, 5 January 2015 (CET)
 +
** '''Minimale Anforderungen definieren'''

Latest revision as of 15:14, 11 January 2015

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
  • 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
Retrieved from "https://wiki.stoney-cloud.org/mediawiki/index.php?title=Talk:stoney_core:_REST_API&oldid=4496"