I have been building a little service bus explorer tool that runs on the major operating systems, and that has proven useful in my day job. The tool is using the Azure.Messaging.Servicebus nuget package. One of the features is the ability to filter on queue / topic / subscription names. Older SDK packages (predecessors), which supported server-side filtering, are deprecated, and unfortunately the current SDK does not support server-side filtering, so I had to fall back to client side filtering instead.
Unfortunately, I found that, in case of a namespace with a lot of queues e.g. (+1900 in my case), the AsyncPageable result does not provide consistent pagination results: both the number of pages returned and the total number of resources (queues e.g.) differ on subsequent runs, which makes the search results inconsistent.
I filed a bug https://github.com/Azure/azure-sdk-for-net/issues/40773 on the SDK project (Azure.Messaging.Servicebus), but the response is that this is a server-side issue (if there is an issue indeed).
The well-known service bus explorer that is widely used, does not have this problem because it uses an older / deprecated client, which still allows for server-side filtering.
So as a last resort, I'm wondering if there are still http / oData endpoints available on the azure service bus, the way they were in older versions of the APIs. I find it quite hard to find some documentation about these endpoints, but maybe I'm missing something.
Does anyone have some hints where I can find some documentation, or suggestions for another approach to do the filtering (except for falling back to older deprecated SDK versions)?
Since the time that legacy package was created, the Azure strategy for resource management shifted, with an emphasis on splitting responsibilities between client libraries (data plane) and management libraries (ARM-based). This is intended to allow for more granular permissions management and a tighter security model. As a result, there is no equivalent API surface for entity management in the Service Bus AMQP API.
For your scenario, using the management package, Azure.ResourceManager.ServiceBus, would be the recommended approach. This package interacts with ARM directly, which is how Azure itself manages resources, including the Azure portal. This API should be much more stable and should offer more consistent results. It is also under active development and is still being invested in. Any bugs that you find are more likely to be addressed in this API than in the alternatives.
The current generation Service Bus client library, Azure.Messaging.ServiceBus, works around the data/management plane limitation by using an older ATOM-based API which allows managing Service Bus entities with data-plane permissions. That API, however, exists for compatibility reasons and is not something under active development. It has some quirks and is mainly useful for scenarios where dynamic creation of queues/topics/subscriptions are needed for an application.
The legacy packages consume the deprecated SBMP protocol, which was a homegrown protocol based on WCF. I don't know of any official protocol documentation that exists. Given that it is scheduled for retirement, using it wouldn't be a viable long-term solution.