AIOps

 View Only

 Missing GET for AIOps topology REST observer API

caio cor's profile image
caio cor posted 06/18/26 01:53 PM

There's something in AIOPS resource management that would make a lot of sense: A feature to inherit certain properties based on the relationship between resources. Let me explain: Imagine that we have a building resource and this building resource has "LocatedAt" edges with various servers and network equipment. In this scenario, it would make perfect sense for all resources that have a "LocatedAt" relationship with this building to inherit the properties of the geojason. Since this feature doesn't exist natively in AIOPS, I started planning to develop it, but I encountered a significant limitation on the REST Observer API side: We have functions to insert, update, and delete resources and relationships, but we don't have functions to retrieve resources from within the AIOPS topology. Therefore, we can't retrieve resources of a specific type. I'd like to know if there's a reason why we don't have a GET function for resources it seems simple to implement. The same occurs for the patch incident in "Issue resolution API".

Matthew Duggan's profile image
Matthew Duggan posted 06/19/26 02:36 AM

Hi, 

The topology, layout and inventory service APIs are the best place to get resource and relationship data once their routes are enabled as described in the docs.  The Observer's are ingest only. 

On your modelling goal - I'd highly recommend treating them as a group instead if there's a likelihood of a given location having many resources, i.e. a supernode.  I would use a token template to do this that uses a property on the resources and if it doesn't exist natively, use a file enrichment rule or file observer-and-merge to provide it. 

thanks,

Matt

Allan Solomon Mejia's profile image
Allan Solomon Mejia posted 06/19/26 11:46 AM

Hi Caio,

That’s a very valid point. A GET function for resources would make REST Observer and Issue Resolution API use cases much more complete, especially for enrichment, inheritance, and topology-driven automation.

The “LocatedAt” example is a strong one because location, geozone, ownership, and support-group metadata often belong to a parent resource but need to be applied consistently to dependent infrastructure.

Without a native resource retrieval function, developers are forced to maintain external mappings or work around the topology model, which reduces the value of AIOps as the system of context.

I would recommend raising this as an RFE/enhancement request. Ideally, the API should support querying resources by type, relationship, tags, and topology attributes, not only insert/update/delete operations.

Related Content