Refactor API Documentation to not contain duplicated values in arrays

[jzbmw]

As Developer, I want to be able to understand the API and don't have duplicated values in arrays so that it is clear what to implement.

Hints / Details

• Example values shall not be shown 5 times
• https://catenax-ng.github.io/tx-item-relationship-service/docs/api-specification/api-specification.html
• To prevent this from happening example data should be added at higher struct level (mock the array not items themselves). This also require refactoring of open-api annotations on controllers levels.
• Bad Example:

  "subjectId" : {
      "keys" : [ {
        "type" : "urn:bamm:com.catenax.vehicle:0.1.1",
        "value" : "Submodel"
      }, {
        "type" : "urn:bamm:com.catenax.vehicle:0.1.1",
        "value" : "Submodel"
      }, {
        "type" : "urn:bamm:com.catenax.vehicle:0.1.1",
        "value" : "Submodel"
      }, {
        "type" : "urn:bamm:com.catenax.vehicle:0.1.1",
        "value" : "Submodel"
      }, {
        "type" : "urn:bamm:com.catenax.vehicle:0.1.1",
        "value" : "Submodel"
      } ],
      "type" : "type"
    } 

Feature:

• eclipse-tractusx/sig-release#450

Acceptance Criteria

• [x] Correct OpenApi documentation in product documentation

Out of Scope

• ...

[ds-psosnowski]

Planning 2: Task itself is tricky since we need to match with api generated by open-api and when doing so, open-api generates 5 items each as an example for static docs (available without running an application). There are 2 possible solutions

1. add examples to whole structures in both documentations, not in declarative way, for example:

   example: 
   {
   "example": {
   "example": "example"
   }
   }

   instead of

   example:
   example:
   example

2. Or just try to match contract precisely with examples and declarations in open-api.yaml with examples specially prepared for arrays (this didn't seemed to work every time but need to be checked).

[ds-psosnowski]

PR: https://github.com/catenax-ng/tx-item-relationship-service/pull/813

[ds-psosnowski]

@mkanal story is ready for review docs can be found here: https://catenax-ng.github.io/tx-item-relationship-service/docs/api-specification/api-specification.html

[mkanal]

[mkanal]

@jzbmw LGFM subjectId was incorrect and now it is according to AAS specification. Ready for PO review. https://catenax-ng.github.io/tx-item-relationship-service/docs/api-specification/api-specification.html#getBPNInvestigation