Talk:stoney core: REST API - Revision history

Michael at 14:14, 11 January 2015

2015-01-11T14:14:05Z

← Older revision		Revision as of 16:14, 11 January 2015
Line 12:		Line 12:
	** 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)		** 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'''		** '''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. --[[User:Tiziano\|Tiziano]] ([[User talk: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) --[[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		* Passwörter

Michael: /* Fragen / Inkonsistenzen */

2015-01-11T13:56:18Z

Fragen / Inkonsistenzen

@@ Line 1: / Line 1: @@
 = Fragen / Inkonsistenzen =
 * Relations (queries/scoping): Haben wir nicht getestet!
@@ Line 42: / Line 12: @@
 ** 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'''
 * Actions

Michael at 16:21, 8 January 2015

2015-01-08T16:21:24Z

← Older revision		Revision as of 18:21, 8 January 2015
Line 72:		Line 72:
	** 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)		*** Zu aufwändig für den Nutzen. --[[User:Tiziano\|Tiziano]] ([[User talk:Tiziano\|talk]]) 12:37, 5 January 2015 (CET)
			** '''Minimale Anforderungen definieren'''

Michael: /* Fragen / Inkonsistenzen */

2015-01-08T16:19:40Z

Fragen / Inkonsistenzen

← Older revision		Revision as of 18:19, 8 January 2015
Line 6:		Line 6:
	*** 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)		*** 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)		**** ACK --[[User:Chrigu\|Chrigu]] ([[User talk:Chrigu\|talk]]) 16:18, 8 January 2015 (CET)
			** '''Create, collection retrieval, search'''

	* Update		* Update
Line 11:		Line 12:
	*** 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)		*** 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)		**** 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		* http://wiki.stoney-cloud.org/wiki/stoney_core:_People_Resource_-_REST_API#People_collection_retrieval_response_message
Line 16:		Line 19:
	** Location würde in diesem Falle dem "current" entsprechen (zwischen "pre" und "next").		** 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)		** 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".		* 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)		** 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.		* 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?		** 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.		* 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!		* Relations (queries/scoping): Haben wir nicht getestet!
Line 35:		Line 41:
	** 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)		** 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)		** 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.		* 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.
Line 44:		Line 51:
	** 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)		** 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)		*** 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~~ Content~~-Header nicht ... Oder geht das zu weit?~~		** '''204 No Content ist OK'''

	* Actions		* Actions
Line 53:		Line 60:
	**** 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)		**** 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)		**** 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		* Passwörter

Chrigu: /* Fragen / Inkonsistenzen */

2015-01-08T15:20:22Z

Fragen / Inkonsistenzen

← Older revision		Revision as of 17:20, 8 January 2015
Line 43:		Line 43:
	*** In diesem Falle würde ich eher "{ "Deletion successful": 1 } erwarten.		*** In diesem Falle würde ich eher "{ "Deletion successful": 1 } erwarten.
	** 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)		** 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 Content-Header nicht ... Oder geht das zu weit?		** Müssten wir nicht auch noch unterschiedliche Response Header zurückgeben? Wenn kein Body, benötige ich auch den Content-Header nicht ... Oder geht das zu weit?

Line 50:		Line 51:
	*** Eine Location für die Status-Abfrage ist nötig! In Form einer Job-ID oder ähnlichem.		*** 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. --[[User:Tiziano\|Tiziano]] ([[User talk:Tiziano\|talk]]) 12:37, 5 January 2015 (CET)		*** 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. --[[User:Tiziano\|Tiziano]] ([[User talk: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) --[[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)		**** 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)

Chrigu: /* Fragen / Inkonsistenzen */

2015-01-08T15:18:29Z

Fragen / Inkonsistenzen

← Older revision		Revision as of 17:18, 8 January 2015
Line 5:		Line 5:
	*** Location müsste bei Update auch nicht hochgeschrieben werden?		*** Location müsste bei Update auch nicht hochgeschrieben werden?
	*** 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)		*** 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)

	* Update		* Update
	** Statt leerem Body wäre hier eine Antwort logisch, wie bei der Kreierung.		** Statt leerem Body wäre hier eine Antwort logisch, wie bei der Kreierung.
	*** 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)		*** 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)

	* http://wiki.stoney-cloud.org/wiki/stoney_core:_People_Resource_-_REST_API#People_collection_retrieval_response_message		* http://wiki.stoney-cloud.org/wiki/stoney_core:_People_Resource_-_REST_API#People_collection_retrieval_response_message

Michael: /* Fragen / Inkonsistenzen */

2015-01-08T15:17:28Z

Fragen / Inkonsistenzen

← Older revision		Revision as of 17:17, 8 January 2015
Line 41:		Line 41:
	*** In diesem Falle würde ich eher "{ "Deletion successful": 1 } erwarten.		*** In diesem Falle würde ich eher "{ "Deletion successful": 1 } erwarten.
	** 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)		** 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)
			** Müssten wir nicht auch noch unterschiedliche Response Header zurückgeben? Wenn kein Body, benötige ich auch den Content-Header nicht ... Oder geht das zu weit?

	* Actions		* Actions

Chrigu at 15:10, 8 January 2015

2015-01-08T15:10:34Z

← Older revision		Revision as of 17:10, 8 January 2015
Line 32:		Line 32:
	** 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)		** 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)

	* 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.		* 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.

Tiziano at 17:03, 7 January 2015

2015-01-07T17:03:12Z

← Older revision		Revision as of 19:03, 7 January 2015
Line 46:		Line 46:
	*** Eine Location für die Status-Abfrage ist nötig! In Form einer Job-ID oder ähnlichem.		*** 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. --[[User:Tiziano\|Tiziano]] ([[User talk:Tiziano\|talk]]) 12:37, 5 January 2015 (CET)		*** 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. --[[User:Tiziano\|Tiziano]] ([[User talk:Tiziano\|talk]]) 12:37, 5 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)

	* Passwörter		* Passwörter

Tiziano at 11:37, 5 January 2015

2015-01-05T11:37:29Z

← Older revision		Revision as of 13:37, 5 January 2015
Line 4:		Line 4:
	** Gehört die Location in die Body Response rein? Falls ja:		** Gehört die Location in die Body Response rein? Falls ja:
	*** Location müsste bei Update auch nicht hochgeschrieben werden?		*** Location müsste bei Update auch nicht hochgeschrieben werden?
			*** 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)

	* Update		* Update
	** Statt leerem Body wäre hier eine Antwort logisch, wie bei der Kreierung.		** Statt leerem Body wäre hier eine Antwort logisch, wie bei der Kreierung.
			*** 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)

	* http://wiki.stoney-cloud.org/wiki/stoney_core:_People_Resource_-_REST_API#People_collection_retrieval_response_message		* 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 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").		** 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)

	* Caching Controls: Manchmal kommt "Cache-Control: no-cache" zurück, manchmal "Cache-Control: none, private".		* 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.		* the service must recognize ETag, Last-Modified and Cache-Control: none provided by the client and act accordingly.
Line 27:		Line 31:
	* 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.		* 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.
Line 34:		Line 39:
	** 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.		** 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.		*** In diesem Falle würde ich eher "{ "Deletion successful": 1 } erwarten.
			** 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)

	* Actions		* Actions
Line 39:		Line 45:
	*** 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.		*** 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.		*** 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. --[[User:Tiziano\|Tiziano]] ([[User talk:Tiziano\|talk]]) 12:37, 5 January 2015 (CET)

	* Passwörter		* Passwörter
Line 47:		Line 54:
	*** 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)