Get Advisor Rule Graph (Reserved)

Renders the object-visualization graph for one Advisor rule, focused on one object returned by GET /rules/:id/objects.

URI

POST /rest/applications/{application}/advisors/rules/{id}/graph

Use the existing authentication and x-user-tenant header. The application name must be URL-encoded when necessary and cannot contain quote or backquote characters. This endpoint is available in Unified builds only. Unlike every other Advisor endpoint in this API, it does not take migration — a rule-specific object graph has no guidance text that could be scoped to the wrong migration, so there is nothing for migration to validate.

Request body

{
  "objectId": "4:f47ac10b-58cc-4372-a567-0e02b2c3d479:9001",
  "version": "3.6.0"
}
Field Meaning
objectId Required. A Neo4j element reference — use the graphId value from one of GET /rules/:id/objects’ objects[] entries for this same rule, not its aipid. It is not a stable, portable identifier; obtain it fresh each session
version Required. The Advisor version this rule’s visualization is defined for

Response

{
  "results": {
    "graph": {
      "nodes": [
        {"id": "4:...:9001", "data": {"Name": "MyClass", "FullName": "pkg.MyClass", "AipId": "obj-123", "Type": "Class"}}
      ],
      "edges": []
    },
    "documents": []
  }
}

results is the existing GraphDocument representation (graph.nodes, graph.edges, documents) used elsewhere in this API, wrapped in results. documents is always empty in this slice — see the deliberate omission below.

A version at or before 2.17.0 returns 400: this rule’s visualization logic changed shape at that version, and the pre-change shape (and the two patch-release-specific rule-ID fallbacks the service used when its newer shape’s fields were absent) are not ported — see the deliberate corrections below. A rule not found for the given id/version, or absent from application, returns 404. Standard API errors apply for invalid application identifiers, missing tenants, a malformed request body, and database failures.

Deliberate corrections versus the source:

  • This endpoint’s visualization queries run through this API’s existing read-only graph executor. The source runs the same stored queries in write mode despite this being a read/visualization operation — imaging-api has no write-capable graph executor at all, by design, so there was no infrastructure this could have been ported onto even if that behavior were intentional there. If a stored query genuinely needs write semantics, it will fail with a clear database error rather than silently produce a wrong graph; this has not been validated against live data, and is the main outstanding risk for this endpoint.
  • Fetching the named visualization queries is batched into one call instead of imaging-service’s one-call-per-query-ID loop, matching the N+1 fix already applied to this API’s effort-count queries.
  • Versions at or before 2.17.0 (AdvisorRule.Operations’s older, flat shape, and the service’s compatibility map for two specific legacy rule-ID lists under versions 2.17.0/2.17.1) are rejected explicitly rather than ported — neither is exercised by any version this API’s other Advisor endpoints already support.
  • documents (linked Document/annotation metadata) are not fetched at all, for the same reason GET /rules/:id/objects omits annotations: porting that lookup is a separate, undecided scope question, not a default to carry over silently.