stoney core: REST API - Revision history

Michael: /* Mandatory headers */

2014-09-07T14:15:57Z

Mandatory headers

← Older revision		Revision as of 16:15, 7 September 2014
Line 440:		Line 440:
	* the service must recognize <code>ETag</code>, <code>Last-Modified</code> and <code>Cache-Control: none</code> provided by the client and act accordingly.		* the service must recognize <code>ETag</code>, <code>Last-Modified</code> and <code>Cache-Control: none</code> provided by the client and act accordingly.
	* every answer to a GET request must include proper <code>Cache-Control</code> headers		* every answer to a GET request must include proper <code>Cache-Control</code> headers
	* every PUT request to update an object must include the <code>ETag</code> provided by the <code>GET</code> request to fetch the object initially. The API must respond with an <code>428 (Precondition Required)</code> if the ETag is missing.		* every PUT and PATCH request to update an object must include the <code>ETag</code> provided by the <code>GET</code> request to fetch the object initially. The API must respond with an <code>428 (Precondition Required)</code> if the ETag is missing.

	''Implementation notes'':		''Implementation notes'':

2014-09-07T14:14:50Z

Notes

← Older revision		Revision as of 16:14, 7 September 2014
Line 596:		Line 596:
	* Nested URLs vs. filter via get parameter => <code>/users/<UID>/products</code> vs. <code>/products/?userId=<UID></code>, (choose a better word for product?)		* Nested URLs vs. filter via get parameter => <code>/users/<UID>/products</code> vs. <code>/products/?userId=<UID></code>, (choose a better word for product?)
	* Sudo mechanism, via custom HTTP header, for example <code>X-USER</code>		* Sudo mechanism, via custom HTTP header, for example <code>X-USER</code>

	~~My test for the next draft version.~~

	[[Category:REST API]][[Category:stoney core]]		[[Category:REST API]][[Category:stoney core]]

2014-08-26T08:51:01Z

Notes

← Older revision		Revision as of 10:51, 26 August 2014
Line 596:		Line 596:
	* Nested URLs vs. filter via get parameter => <code>/users/<UID>/products</code> vs. <code>/products/?userId=<UID></code>, (choose a better word for product?)		* Nested URLs vs. filter via get parameter => <code>/users/<UID>/products</code> vs. <code>/products/?userId=<UID></code>, (choose a better word for product?)
	* Sudo mechanism, via custom HTTP header, for example <code>X-USER</code>		* Sudo mechanism, via custom HTTP header, for example <code>X-USER</code>

			My test for the next draft version.

	[[Category:REST API]][[Category:stoney core]]		[[Category:REST API]][[Category:stoney core]]

2014-08-26T08:39:49Z

Undo revision 4207 by Michael (talk)

← Older revision		Revision as of 10:39, 26 August 2014
Line 1:		Line 1:
	= Overview =		= Overview =
	~~ssss~~
	= Entities, Roles and Relationships =		= Entities, Roles and Relationships =
	== Overview ==		== Overview ==

2014-08-26T08:15:37Z

← Older revision		Revision as of 10:15, 26 August 2014
Line 1:		Line 1:
	= Overview =		= Overview =
			ssss
	= Entities, Roles and Relationships =		= Entities, Roles and Relationships =
	== Overview ==		== Overview ==

2014-08-23T21:25:30Z

Error codes and responses

← Older revision		Revision as of 23:25, 23 August 2014
Line 346:		Line 346:
	\| Bad Request		\| Bad Request
	\| The request was invalid. A descriptive error message will be sent within the response body.		\| The request was invalid. A descriptive error message will be sent within the response body.

			\|-
			\| 401
			\| Unauthorized
			\| The client has failed or not yet tried to authenticate.

			\|-
			\| 403
			\| Forbidden
			\| The client is not allowed to access the requested resource.

	\|-		\|-
Line 358:		Line 368:

	\|-		\|-
	\| ~~401~~		\| 409
	\| ~~Unauthorized~~		\| Resource Conflict
	\| ~~The client has failed or not yet tried to authenticate.~~		\| State of the resource doesn't permit request.

	\|-
	~~\| 403~~
	~~\| Forbidden~~
	~~\| The client is not allowed to access~~ the ~~requested~~ resource.

	\|-		\|-

2014-08-06T13:48:18Z

Error codes and responses

← Older revision		Revision as of 15:48, 6 August 2014
Line 408:		Line 408:
	"error": {		"error": {
	"module": "core",		"module": "core",
	"code": ~~123~~,		"code": 422,
	"message": "~~Validation failed~~"		"message": "The request was well-formed but was unable to be followed due to semantic errors."
	"details" : [		"details" : [
	{		{
	"module": "core",		"module": "core",
	"code" : ~~5432~~,		"code" : 1006,
	"field" : "~~firstName~~",		"field" : "isCompany",
	"message" : "~~First name cannot~~ be ~~longer than 35 characters~~"		"message" : "is invalid, true or false will be accepted"
	},		},
	{		{

2014-08-06T07:29:47Z

Input validations

← Older revision		Revision as of 09:29, 6 August 2014
Line 583:		Line 583:

	=== Input validations ===		=== Input validations ===
	The service validates all input it receives from a client and returns a <code>422</code> (Unprocessable Entity) HTTP [[#Error_codes_and_responses\|error code with a descriptive error object]].		The service validates all input it receives from a client and returns a <code>422</code> (Unprocessable Entity) HTTP [[#Error_codes_and_responses\|status code together with a descriptive error object]] in case of an input violation (but well-formed JSON).

			In case a client passes invalid JSON (a JSON parser is unable to parse the JSON string), the service returns a <code>400</code> (Bad Request) HTTP [[#Error_codes_and_responses\|status code together with a descriptive error object]] containing the JSON parser error message.

	= Notes =		= Notes =

2014-08-06T07:18:52Z

Error codes and responses

2014-08-04T13:16:47Z

Relationships

← Older revision		Revision as of 15:16, 4 August 2014
Line 35:		Line 35:
	'''Service Provider Person''' > '''Reseller Employee''' > '''Customer Employee''' > '''Reseller Person''' and '''Customer Person'''		'''Service Provider Person''' > '''Reseller Employee''' > '''Customer Employee''' > '''Reseller Person''' and '''Customer Person'''

	The further down you go, the less rights ~~you have~~ (this is currently independent from any existing roles, as these have not been finalized yet).		The further down you go, the less rights a person has (this is currently independent from any existing roles, as these have not been finalized yet).

	=== Service Provider Person (SPP) ===		=== Service Provider Person (SPP) ===