Some objects in the OpenAPI spec are incorrect

[jkoenig134]

Readiness checklist

• I added/updated tests.
• I ensured that the PR title is good enough for the changelog.
• I labeled the PR.

Description

Fixes nmshd/feedback#29

Fixed issues:

• @type is displayed as required in RequestResponseContent
• peerIdentity is missing in Relationship

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

see 1 file with indirect coverage changes

[Milena-Czierlinski]

@jkoenig134 What information is actually supposed to be given in the openapi.yml file? I don't completely see what pattern we are following there.

[jkoenig134]

I don't get your question. In a perfect world openapi and the results would be 1:1 the same. It's hard to archieve that, so I fixed these bugs.
If you find more feel free to mention that :)

[Milena-Czierlinski]

I had trouble finding the data structure that is returned as a result so that I might compare them. Where do I see how the returned object will occur?

Another question that is principally unrelated to your changes: Why do we have peer and peerIdentity?

[jkoenig134]

I had trouble finding the data structure that is returned as a result so that I might compare them. Where do I see how the returned object will occur?

Another question that is principally unrelated to your changes: Why do we have peer and peerIdentity?

The Data structure is RelationshipDTO.

Regarding peer and peerIdentity: I think for easier / more performant querying.

[Milena-Czierlinski]

And is @type never required?

[jkoenig134]

@type is not rendered out by ts-serval when the property can only have one @type, to save bandwidth.

[britsta]

Regarding peer and peerIdentity: I think for easier / more performant querying.

Should we also add the peerIdentity property to the documentation of the Relationship in the Data Model Overview then? I also thought it was weird to have a peer property in addition to the peerIdentity property. I wonder how we can present this redundance in a meaningful way in the documentation.

[jkoenig134]

we should document it, yes.