Missing Location header field on resource creation with a POST

[pohutukawa]

Describe the bug
It is common in RESTful CRUD services to return the resource URI of a newly created resource with a POST HTTP operation via the Location header field. Many operations (e.g. creation of a DID) return information on the new resource name in the response body as a string (even though the request has specified an accepted type application/json). However, when importing a JWK key, only an empty response body is returned, and the resource or keyId of the new key is completely unknown (unless a kid element was part of the JWK imported already).

It is customary to use the HTTP protocol on RESTful CRUD operations by specifying the Location header field with the full URI to the created resource. That also eliminates the need of a HTTP body in the response. (If I'm picky, we'd expect a 201 Create response here instead of a 200 OK, but that's tolerable if the information is available).

To Reproduce
Steps to reproduce the behaviour:

1. Import a new key via a JWK with a POST /wallet-api/wallet/{wallet}/keys/import
2. Receive a 200 OK response
3. Inspect all the header fields and the body of the response, without any indication of the newly created key ID or resource URI given

Expected behaviour
Preferably the new resource URI in the Location header field of the response. Alternatively (or both) the resource URI or minimally the new key ID in the response body.

Actual behaviour
Unidentifiable key ID or new key's resource URI.

Environment
curl command line, scripted (e.g. Python) or via the Swagger UI.

[cpatsonakis]

Hi!

Thank you for bringing this issue to our attention.

As this affects multiple CRUD-based endpoints of the Wallet API, further investigation is required to
organize, probably multiple, PRs towards a resolution.

We will update this issue accordingly following our internal discussion.

Thanks again!

[SuperBatata]

should be fixed with this pr : #597