Simplification of Semantic Model API Endpoints due to Standard#0003

[jjeroch]

Description: We need to simplify our API endpoints for semantic models by removing the model type attribute/parameter. As per the latest standard defined in the document CX-0003-SAMMSemanticAspectMetaModel-v1.1.0, only SAMM (Semantic Aspect Meta Model) types will be supported going forward. Hence, the attribute that specifies the semantic model type in API requests and responses is no longer necessary and should be removed to reflect this change.

Acceptance Criteria:

1. The type parameter should be removed from all API endpoints that currently include it.
2. The API documentation should be updated to reflect the removal of the type parameter.
3. All API responses should no longer include the type attribute in the JSON body.
4. Ensure that all associated functionality (filtering, sorting, etc.) that relies on the type parameter is either removed or adjusted to work without it.
5. Conduct thorough testing to confirm that the API endpoints function correctly after the removal of the type parameter.
6. Update any internal or external clients that consume these endpoints to ensure they are compatible with the changes.

Affected Endpoints:

• POST /hub/api/v1/models
• GET /hub/api/v1/models
• PUT /hub/api/v1/models
• GET /hub/api/v1/models/{urn}
• PUT /hub/api/v1/models/{urn}

Tasks:

1. Review the relevant API code to identify all instances where the type attribute is used.
2. Modify the API endpoint handlers to remove the type attribute from the request and response handling logic.
3. Update unit and integration tests to align with the changes.
4. Update API documentation and any example requests and responses to ensure they no longer include the type attribute.
5. Perform regression testing to ensure API stability post-changes.
6. Communicate changes to all stakeholders and update any affected systems or documentation that references the old API structure.

---

Test Cases for Simplification of Semantic Model API Endpoints

Test Cases for Simplified Semantic Model API Endpoints

Test Case 1: Verify Removal of type Parameter in POST Request

• Objective: Ensure the POST endpoint functions without the type parameter.
• Steps: Send a POST request to create a new semantic model without including the type parameter.
• Expected Result: The API should accept the request and create a new semantic model without requiring a type.

Test Case 2: Verify GET List Endpoint Without type Parameter

• Objective: Confirm that the GET list endpoint returns semantic models without the type attribute.
• Steps: Send a GET request to list all semantic models without any type parameter.
• Expected Result: The response should list semantic models without including a type attribute in the JSON body.

Test Case 3: Verify PUT Endpoint Without type Parameter

• Objective: Confirm that the PUT endpoint updates semantic models without the type parameter.
• Steps: Send a PUT request to update an existing semantic model's details without including the type parameter in the request body.
• Expected Result: The model should be updated successfully, and the response should not include a type attribute.

Test Case 4: Verify GET Individual Model Endpoint Functionality

• Objective: Ensure the GET endpoint for an individual model does not return a type attribute.
• Steps: Send a GET request to retrieve a specific semantic model by its URN.
• Expected Result: The response should provide the model's details without a type attribute.

Test Case 5: Verify PUT Individual Model Endpoint Functionality

• Objective: Ensure the PUT endpoint for an individual model updates without the type parameter.
• Steps: Send a PUT request to update a specific semantic model by its URN without including the type parameter in the request body.
• Expected Result: The model should be updated successfully, and the response should not include a type attribute.

Test Case 6: Confirm Filtering Without type Parameter

• Objective: Verify that filtering based on the type parameter is no longer available.
• Steps: Attempt to send a request with a type filter applied.
• Expected Result: The API should either ignore the type filter or return an error indicating that filtering by type is not supported.

Test Case 7: Validate API Documentation Update

• Objective: Confirm that the API documentation no longer mentions the type parameter.
• Steps: Review the updated API documentation to ensure it is consistent with the changes.
• Expected Result: All references to the type parameter should be removed.

Test Case 8: Backward Compatibility Check

• Objective: Ensure that legacy clients not sending the type parameter are not affected.
• Steps: Use a client setup similar to a pre-update state (omitting the type parameter) to interact with the API.
• Expected Result: API should function correctly, and no errors should occur due to the absence of the type parameter.

Test Case 9: Error Handling for type Parameter

• Objective: Verify that the API handles requests with the type parameter gracefully.
• Steps: Intentionally send a request that includes the type parameter.
• Expected Result: The API should ignore the type parameter or respond with an appropriate error message indicating that the parameter is no longer supported.

Test Case 10: Comprehensive Regression Testing

• Objective: Perform a full regression test to ensure no other functionalities are affected.
• Steps: Execute all existing test cases for the semantic model API endpoints.
• Expected Result: All tests should pass, and no new issues should be introduced as a result of the changes.

---

Additional Information

• [x] I am willing to contribute

Milestones

• Code delivery: 14th of August

[jSchuetz88]

Hi @jjeroch, there are currently still 5 standardised BAMM models that have not yet been updated. Could this be a possible blocker / dependency for this issue?

[stephanbcbauer]

@jjeroch @MaximilianHauer not sure about this feature. Should it be part of tomorrow's presentation? ⇾ Since the status is still Inbox