feat(core): DELETE entity endpoint

[RVANDO12]

PR Description

What this PR Provides

• new endpoint for DELETE Entity
• add status on entity CREATED, ARCHIVED, UPDATED
• DELETE : Remove an entity from the system using its identifier and template identifier
• DELETE : Validate remove only if not link to a relation required, and prevent orphan when removed entity
  . Rule 1 (Optional relationship): If the parent entity points to the deleted entity, and this relationship required: false in its Template, the relationship is simply removed from the parent entity in the database.
  . Rule 2 (Mandatory relationship): If the parent entity points to the deleted entity, and the relationship required: true, and it was the only target entity (to_many cardinality: false or array became empty), the deletion prime on relation and the relations was updated after deletion of entity.

Review

The reviewer must double-check these points:

• The reviewer has tested the feature
• The reviewer has reviewed the implementation of the feature
• The documentation has been updated
• The feature implementation respects the Technical Doc / ADR previously produced

How to Test the DELETE Entity Endpoint

This guide outlines the functional testing strategy for the DELETE /api/v1/entities/{templateIdentifier}/{entityIdentifier} endpoint based on the integration test suite (EntityControllerTest) and the OpenAPI specification.

The primary objective of this test case is to ensure that deleting an entity not only removes the target entity itself but also idempotently cleans up all incoming relations from other parent/source entities, preventing dangling or orphan references in the system.

---

1. Endpoint Overview

According to the OpenAPI specification, the endpoint details are as follows:

• HTTP Method: DELETE
• Path: /api/v1/entities/{templateIdentifier}/{entityIdentifier}
• Security: Requires an authenticated user (@WithMockUser) and a valid CSRF token.
• Expected Responses:
  • 204 No Content: Successful deletion or relation cleanup completed.
  • 401 Unauthorized: Missing or invalid authentication token.
  • 403 Forbidden: Missing CSRF token or insufficient rights.
  • 404 Not Found: Entity or template does not exist.
  • 500 Internal Server Error: Unexpected server failure (e.g., blank path parameters).

---

2. Test Setup & Prerequisites

To thoroughly validate the deletion workflow and its side effects (cascading relation cleanups), you must establish a multi-entity relational lifecycle model.

Step 1: Ensure an Entity Template Exists

An entity cannot exist without a valid parent schema template.

• Action: Verify or create an EntityTemplate (e.g., web-service) that defines the necessary schema properties and relation definitions.

Step 2: Create the Target Entity (The Entity to Delete)

This entity will be the target of the DELETE request.

• Action: Send a POST /api/v1/entities/web-service request.
• Payload:

  {
    "name": "Relation Target Entity",
    "identifier": "relation-target-entity",
    "properties": {
      "applicationName": "catalog-api",
      "ownerEmail": "owner@example.com",
      "port": "8080",
      "environment": "DEV",
      "version": "1.2.3",
      "teamName": "platform-team",
      "baseUrl": "[https://catalog.example.com](https://catalog.example.com)",
      "protocol": "HTTP",
      "programmingLanguage": "JAVA"
    }
  }

• Expectation: 201 Created.

Step 3: Create the Source Entity with a Multi-Relation Link

To test the cascading relational cleanup, a second entity must be created that declares a dependency or relation pointing to the target entity created in Step 2.

• Action: Send a POST /api/v1/entities/web-service request.
• Payload:

  {
    "name": "Relation Source Entity",
    "identifier": "relation-source-entity",
    "properties": { 
      "applicationName": "source-api",
      "ownerEmail": "source@example.com",
      "port": "9090"
    },
    "relations": [
      {
        "name": "database",
        "target_entity_identifiers": ["relation-target-entity"]
      }
    ]
  }

• Expectation: 201 Created.

---

3. Test Execution Workflow

Once the environment state is prepared, execute the deletion process sequentially.

Flow: [Source Entity] --(points to)--> [Target Entity]

1. Executing DELETE on Target Entity
2. Target Entity is removed from DB (204)
3. Source Entity's relations are automatically updated (200 OK)

Step 4: Execute the DELETE Request

Perform the destructive action on the target entity identifier while supplying appropriate mock authentication and CSRF protection headers.

• Action: Invoke DELETE /api/v1/entities/web-service/relation-target-entity

---

4. Verification & Assertions

A successful test must guarantee data consistency across three distinct structural checks:

Step 5: Assert Deletion Success

• Immediate Response: The HTTP status code returned by the server must be exactly 204 No Content.

Step 6: Verify Target Non-Existence (Read-After-Delete)

• Action: Perform a GET /api/v1/entities/web-service/relation-target-entity.
• Assertion: The system must return a 404 Not Found status code, ensuring that the record has been fully removed from active storage.

Step 7: Verify Relationship Cleanup on the Source Entity

This is the critical functional boundary validation. The source entity itself must not be deleted, but its internal metadata array mapping the relation to the target entity must be automatically scrubbed.

• Action: Perform a GET /api/v1/entities/web-service/relation-source-entity.
• Assertions:
  1. The response code must be 200 OK (the source entity still safely exists).
  2. The JSON response string under the relations block must not contain the string "identifier":"relation-target-entity". The database layer must cleanly un-link the reference.

---

Breaking changes

N/A

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud