That question is like asking "can you tell me something the Twitter API solves that http does not?" - it doesn't make any sense. They are distinct layers. One b

That question is like asking "can you tell me something the Twitter API solves that http does not?" - it doesn't make any sense. They are distinct layers. One builds on the other. http+websocket is a way to set up a full-duplex stream of messages where messages are anything you like. dbus does have that part, but then it defines additionally what the messages actually look like in enough detail to bind them to method calls; it defines semantics such as guaranteed ordering and errors; it defines a central bus daemon; it adds broadcast messages over the daemon; it adds security features to allow mixing user and system domains; it adds a way to locate the bus daemon; it adds a way to launch and track the lifecycle of named processes; etc, a number of other APIs. It is not just a socket. Could you implement a dbus-equivalent using http? Sure. But http does not include a "free" implementation of dbus, any more than it includes an implementation of Twitter. dbus-on-http would have to define how method signatures and types map into http, and then it would still have to actually implement the daemon with its features and semantics. http wouldn't make any material difference here; it would have some bikeshed-level pros and cons, but not change the system design in a material way.