Get Advisor Step Rules (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 rules directly attached to each requested step (from GET /steps or POST /tree), matching the service’s IS_MADE_OF semantics.

URI

POST /rest/applications/{application}/advisors/steps/rules

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.

Request body

{
  "ids": [205],
  "migration": "Move to AWS",
  "version": "3.6.0"
}

Field	Meaning
`ids`	One or more step IDs to fetch rules for; must be non-empty and contain only positive IDs
`migration`	The migration name returned as `migration` from `GET /steps`; required
`version`	The Advisor version returned from `GET /steps`; required

Descendant discovery uses POST /tree; this endpoint does not flatten a whole subtree, only the rules directly attached to each requested step. A shared rule may appear under multiple requested steps; deduplicate rule IDs when gathering findings across steps.

Response

Illustrative response (IDs and counts are examples):

{
  "results": [
    {
      "id": 205,
      "name": "Update database drivers",
      "rationales": "Guidance for this step.",
      "violations": [
        {
          "aipid": 9001,
          "name": "Avoid deprecated driver API",
          "description": "Detail about the rule.",
          "count": 4
        }
      ]
    }
  ]
}

Field	Meaning
`id`	The requested step’s ID, echoed back
`name`	The step’s name
`rationales`	Explanation for the step; omitted when empty
`violations[].aipid`	Numeric AdvisorRule AipId; pass to `/rules/:id/details` for its guidance metadata. Retrieving its affected objects (`/rules/:id/objects`) is not yet implemented
`violations[].name`	Rule name
`violations[].description`	Rule description; omitted when empty
`violations[].count`	Count of distinct affected objects for this rule under the requested step

This endpoint does not return effort; effort is available from GET /steps and POST /tree. Requested step IDs with no matching rules, or that exist but belong to a different migration’s hierarchy, return 200 with {"results":[]}. Standard API errors apply for invalid application identifiers, missing tenants, malformed request bodies, and database failures.

Deliberate corrections versus the source query:

migration now also scopes which requested step’s rules can be returned, not just which text the rationale is read from. The source only checks the requested ID against the version, so a valid step ID from a different migration could still return rules under a migration it does not belong to.
violations[].count now excludes deleted objects, requires an Object/SubObject type, and requires the same ObjectProperty/AdvisorProperty label combination POST /tree’s TASK-entry count already required — the source has a looser, unfiltered match here, which could make the two endpoints disagree on the affected-object count for the same rule.
A step with both a migration-specific and an Agnostic rationale previously produced two entries with the same id and different rationales text, each with only part of that step’s rules — the source relabels every non-matching rationale to ‘Agnostic’ independently instead of picking one. Rationale resolution now picks exactly one, and every rule attached to the step appears in that single entry.
A step with no rationale at all previously vanished from the response entirely rather than appearing with rationales omitted, because the source’s rationale lookup can match zero rows and silently drop the whole group. It now always appears when it has rules.
A version before 2.20.0-alpha1 (no AdvisorMap) previously returned {"results":[]} for every request, because the source requires an AdvisorMap match unconditionally. It now falls back to Agnostic rationale for those versions instead, matching POST /tree’s existing behavior. GET /rules/:id/details does not get this same fallback — see that endpoint’s docs for why.