Hey folks! While we're wrapping up the development of Prime Infrastructure 3.5 and preparing it for release, I thought I'd update you with some of the changes that we're bringing to the Prime Infrastructure API in 3.5.
Removal of DevNet Integration
Previously, in the 3.2 release of Prime Infrastructure, we added a feature that integrated the discussions on our DevNet community forum into the documentation. See our blog post about it for more details. When the merger of the old communities platform and the Cisco support forums was announced, we knew that we would need to revisit this feature. Unfortunately, as we looked into it, we discovered that the approach that we used on the old platform would not work on our new, merged, platform. After discussing with folks that manage this in Cisco, and a brief conversation with the vendor, we decided that the best course of action would be to remove this feature from the documentation. With that one bit of bad news out of the way, let's turn our attention to the good news.
Access Point Rx Neighbors
We've heard from a lot of you that one of the API features that you've been looking for is the ability to fetch Rx neighbors via the API. I'm pleased to let you know that we've implemented such an API resource in Prime Infrastructure 3.5. The new API resource, GET op/apService/rxNeighbors, takes in one access point ID (the ID Prime assigns, which you can get from GET data/AccessPoints) and returns a list of neighbors. Included in that response list is the slot ID and MAC address of the interface that discovered the neighbor; the MAC address of the neighbor; the ID, slot ID, name, service domain, and IP address of the neighbor if known; the neighbor's channel and channel bandwidth, radio band, and RSSI. While Prime Infrastructure has supported fetching this information via the UI for quite some time, it does not persist this information in it's internal database. For this reason, please be aware that querying this resource will result in Prime Infrastructure reaching out to your network to fetch live data.
Event Streams via W3C Server-Sent Events
Another big ask from many of our API users has been the ability to get events and updates as soon as they happen, without having to regularly poll API resources over and over again. So, in essence, as soon as something happens, you've wanted Prime Infrastructure to notify you. We've been working on this for quite some time. We wanted to ensure that we picked the right approach that would integrate well into our existing API framework and Prime Infrastructure as a whole.
The technology that we've settled on is W3C server-sent events (SSE). SSE allows us to send you events, as soon as Prime Infrastructure is aware of them. SSE works by having your client initiate a long running HTTPS connection to Prime Infrastructure. This connection allows for asynchronous, one-way communication from Prime Infrastructure to you. Over SSE, we can push out events as they happen.
There are multiple open-source SSE libraries and clients out there to help accelerate your adoption of this new feature, so you can focus on your specific use cases and business needs.
We will be releasing SSE resources for generic alarms, rogue AP alarms, and CLI templates in Prime Infrastructure 3.5. We're also planning on broadly expanding this new feature with plenty more SSE resources in the next major release of Prime Infrastructure, but I can't share any details on that just yet. However, please let us know in the comments which SSE resources you'd like to see.
Stay Tuned for More!
I know some of you interested in our new SSE feature would probably like more details. I'll be putting up another post next week that walks through some of the specifics of our SSE implementation. I'll demonstrate how you can use one of the open-source libraries to quickly write up a Prime Infrastructure SSE client, and show how it works in detail.
If you have any questions regarding this please leave a comment, and I'll either get back to you as a reply or give you an answer in my upcoming blog post!
