We make some good stuff in the Azure Service Bus team and we tend to make it fairly quickly (both as it operates and as we iterate). For both Messaging (Queues & Topics) and Event Hubs we favor the AMQP protocol because the performance it gives us - including things like flow control and a reusable channel. We do support HTTP for most functionality - but not all. We get a lot of asks for HTTP, but as we dig deeper what we often find is that people want to use an HTTP transport, but not REST itself. People like our .NET client and so do I - it's got some great features. Ultimately what people normally want is to not have to change their firewalls to accommodate the standard AMQP ports. Makes sense.
As a result we've lately had quite a few request for Web Sockets. If you're not familiar with those checkout that link. Cool info. The takeaway is that networks see these connections as an HTTP request and let them through and then the connection is upgraded to a two way TCP channel.
Yesterday someone asked about using Event Hubs from HTTP and this lead to they why question and when I got to the base of it the real ask was for Web Sockets. Well - it must be grant a wish Friday because we actually already implemented that.
When using the Service Bus .NET client simple make one call before opening any connections to Service Bus:
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
This will channel all AMQP connections, the default for Service Bus, over Web Sockets. This setting is in the Microsoft.ServiceBus namespace.