return newly created space in response

[C0rby]

Description

Added the newly created space in the response for CreateSpace and changed the response code to 201. Before the response was empty and returned a 200 OK.

Requires this Reva change: cs3org/reva#2158

Motivation and Context

This is compatible to what Microsoft is doing in the Graph API:
https://docs.microsoft.com/en-us/graph/api/user-post-users?view=graph-rest-1.0&tabs=http#response-1
https://docs.microsoft.com/en-us/graph/api/user-post-calendars?view=graph-rest-1.0&tabs=http#response-1

How Has This Been Tested?

• locally in the graph explorer

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[wkloucek]

@C0rby this needs a rebase, CI was fixed in 90246d7

[ownclouders]

💥 Acceptance tests Core-API-Tests-ocis-storage-4 failed. The build is cancelled...

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

0.0% Coverage
0.0% Duplication

[refs]

👍 as per the docs:

Upon successful completion the service MUST respond with either 201 Created and a representation of the created entity, or 204 No Content

sauce

I think we should aim to be OData compatible, and not use the ms docs as reference? Thoughts @C0rby @butonic

I messaged the maintainer of OData regarding taking over maintenance of the library and await for a response :)

[C0rby]

+1 as per the docs:

> > Upon successful completion the service MUST respond with either 201 Created and a representation of the created entity, or 204 No Content

sauce

I think we should aim to be OData compatible, and not use the ms docs as reference? Thoughts @C0rby @butonic

Oh there is more to that sentence:

204 No Content if the request included a Prefer header with a value of return=minimal and did not include the system query options $select and $expand.

So if we want to support the full functionality, we need to add some more logic.

[refs]

exactly, this is why I brought this up there is more to MSGraph than just their implementation. On the one hand we should focus on OData, but on the other hand we use the msgraph client so it is tied to their implementation of OData, which is pretty flexible. If we use the graph explorer to test the graph API then we are marrying with MSGraph, not OData.