Get Advisor Rule Details (Reserved)

RESERVED: The keyword RESERVED annotation means that the API is available for use but is not yet part of the officially supported specification. Its behavior, interface, or output may change in future releases without backward compatibility guarantees.

Returns the guidance metadata (name, description, rationale, remediation, template type) for one Advisor rule, scoped to a migration and version.

URI

GET /rest/applications/{application}/advisors/rules/{id}/details?migration={migration}&version={version}

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. migration and version are required query parameters — retain the values from your original GET /steps call, or from POST /tree’s migration/version fields (which echo the requested migration, not the parent’s own name — see that endpoint’s step field for the name). POST /steps/rules does not return migration or version at all, so carry them from GET /steps or POST /tree instead. This endpoint is available in Unified builds only.

Response

Illustrative response (values are examples):

{
  "results": {
    "id": 9001,
    "migration": "Move to AWS",
    "version": "3.6.0",
    "name": "Avoid deprecated driver API",
    "description": "This rule flags use of a deprecated database driver.",
    "rationale": "Why this rule matters for this migration.",
    "remediation": "How to fix occurrences of this rule.",
    "templateType": "default-table"
  }
}

Field	Meaning
`id`	The requested rule ID, echoed back
`migration`	The requested migration name, echoed back
`version`	The requested Advisor version, echoed back
`name`	Rule name
`description`	Rule description; omitted when empty
`rationale`	Migration-specific rationale where available, falling back to the rule’s Agnostic rationale; omitted when neither is available
`remediation`	Migration-specific remediation where available, falling back to the rule’s Agnostic remediation; omitted when neither is available
`templateType`	The rule’s row template identifier. It will be used by `GET /rules/:id/objects` to interpret that endpoint’s `values`; that endpoint is not yet implemented

This endpoint does not return effort, severity, blocker status, effort hours, or a documentation URL — effort is available from GET /steps and POST /tree; the others are not established by the underlying Advisor data.

A rule not found for the given id/version, not reachable from an Advisor hierarchy named migration, not present in application (no matching finding), or a migration that does not match an AdvisorMap entry for that version, returns 404. A version before 2.20.0-alpha1 (before AdvisorMap existed) returns 400: this endpoint’s rationale and remediation selection has no non-AdvisorMap fallback defined anywhere in source, so there is no guidance to return for those versions — unlike POST /tree and POST /steps/rules, which fall back to Agnostic rationale for legacy versions. Standard API errors apply for invalid application identifiers, missing tenants, missing migration/version, and database failures.

This endpoint reuses imaging-service’s AdvisorRuleObjectTable rationale/remediation selection (RationaleType = AdvisorMap.RationaleKey for rationale, RemediationType = AdvisorMap.RemediationKey for remediation), trimmed to metadata only — it does not run the object-row traversal used by GET /rules/:id/objects. imaging-service’s other table path (GetAdvisorTableData) selects remediation using RationaleKey instead of RemediationKey; that discrepancy is tracked separately and is not reproduced here.

Three deliberate corrections versus the source query:

Rationale and remediation are collected and read back independently rather than concatenated into one list and read back by position (the source’s positional assembly can put remediation text into the rationale field when rationale is missing but remediation exists).
The migration/version lookup is a required match evaluated before rationale/remediation are collected, not nested inside those collections, so an incompatible migration reliably returns 404 instead of a 200 with empty guidance.
The rule is required to be reachable from an Advisor node named migration, and to have an AdvisorProperty for application. The source’s metadata query has neither check — AdvisorRule and AdvisorMap are matched independently by node existence only, so without this addition a rule from an unrelated migration, or one absent from the application, could return 200 with unrelated guidance instead of 404.