*** es kommt drauf an: bei einer Collection/Such-Resultat/Liste sollte bei jedem einzelnen Element eine Location mitgegeben werden unter welchem das (vollständige) Element abgerufen werden kann. Als Teil eines Elements macht es meistens keinen Sinn. Im Header sollte es nur als Antwort vom Server kommen bei einem POST-Request (also beim Erstellen einer neuen Ressource) zusammen mit einem 201, siehe [http://en.wikipedia.org/wiki/HTTP_location Wikipedia] --[[User:Tiziano|Tiziano]] ([[User talk:Tiziano|talk]]) 12:37, 5 January 2015 (CET)
**** ACK --[[User:Chrigu|Chrigu]] ([[User talk:Chrigu|talk]]) 16:18, 8 January 2015 (CET)
** '''Create, collection retrieval, search'''
* Update
*** Die Antwort ist gemäss REST mit dem Code 200 bereits gegeben. Vielleicht auch hier 204 verwenden stattdessen. --[[User:Tiziano|Tiziano]] ([[User talk:Tiziano|talk]]) 12:37, 5 January 2015 (CET)
**** Ja, strikt gsehen müsste hier 204 zurückkommen. Inhalt brauch es meinern Meinung nach nicht, beim Update ist ja die Location und Id, im gegensatzt zu Create, bereits bekannt. --[[User:Chrigu|Chrigu]] ([[User talk:Chrigu|talk]]) 16:18, 8 January 2015 (CET)
** '''204 und leerer Body'''
** '''Content-Type: application/json; charset=utf-8''' immer zurückgeben.
* http://wiki.stoney-cloud.org/wiki/stoney_core:_People_Resource_-_REST_API#People_collection_retrieval_response_message
** Location würde in diesem Falle dem "current" entsprechen (zwischen "pre" und "next").
** Gemäss HTTP Protokoll auch nicht vorgesehen. Fehler in der Definition --[[User:Tiziano|Tiziano]] ([[User talk:Tiziano|talk]]) 12:37, 5 January 2015 (CET)
* '''Location aus Spez raus bei Collection'''
* Caching Controls: Manchmal kommt "Cache-Control: no-cache" zurück, manchmal "Cache-Control: none, private".
** ich vermute dass hier der Webserver noch was selbst macht --[[User:Tiziano|Tiziano]] ([[User talk:Tiziano|talk]]) 12:37, 5 January 2015 (CET)
* 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?
** '''Cache-Control auf nicht cachen setzen, wenn nichts anderes angegeben ist'''. -> definieren
** '''Nur Server Kontrolle oder auch Cache-Control vom Client?''' -> Abklären
* Mit belongsToResellerId und belongsToCustomerId sind wir inkonsequent. Manchmal haben wir eine belongsToResellerId, manchmal nicht.
** '''Falls es nicht zu Problemen/Inkonsistenz kommt, belongsToResellerId nur zurückgeben, wenn der Benutzer ein Super User ist.'''
* Relations (queries/scoping): Haben wir nicht getestet!
** 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)
** 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)
** '''403 ist OK'''
* 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.
** Gemäss [http://stackoverflow.com/questions/2342579/http-status-code-for-update-and-delete Stackoverflow] ist sowohl 200 als 204 ok. Wir haben uns scheinbar für 200 entschieden. Ein Client wird vermutlich nur auf 200/204 prüfen und den Body sowieso ignorieren, von daher egal. Ich persönlich würde 204 nehmen damit wir keinen Text zurückgeben müssen. --[[User:Tiziano|Tiziano]] ([[User talk:Tiziano|talk]]) 12:37, 5 January 2015 (CET)
*** ACK --[[User:Chrigu|Chrigu]] ([[User talk:Chrigu|talk]]) 16:20, 8 January 2015 (CET)
** Müssten wir nicht auch noch unterschiedliche Response Header zurückgeben? Wenn kein Body, benötige ich auch den '''204 No Content-Header nicht ... Oder geht das zu weit? ist OK'''
* Actions
**** Finde ich gefährlich, der Client macht weiter obschon es das Objekt noch gar nicht gibt/geben wird (im Fehlerfall) --[[User:Chrigu|Chrigu]] ([[User talk: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: [http://www.rabbitmq.com/ RabbitMQ]/[https://github.com/videlalvaro/RabbitMqBundle RabbitMQ Symfony Bundle] und [http://www.celeryproject.org/ Celery] --[[User:Tiziano|Tiziano]] ([[User talk: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