Webhooks are in need of some standardisation for sure, so moving towards something like PuSH is a step in the right direction. However this technology has been around for a while, so whether this will become standard or not remains unclear.<p>PuSH solves a couple annoyances with webhooks that comes to my mind:<p>- Lack of debuggability: the inability to subscribe to events forces me to explicitly set up callback URL(s) on service providers' dashboards or in query strings in requests. IF I managed to set them up correctly, data will come crashing in any day in the future, throwing exceptions, or bouncing on unspecified routes. And all these POST catchers and local tunnels developers play with to get this right in the first place.<p>- Ad-hoc verification schemes: Every service comes up with their own way of ensuring the data originated from their servers. Signature hashes as 'X-*'-headers, a number of extra fields inside the JSON body, etc.<p>There are more, but these two has annoyed me for quite some time.
Nice article with a concise overview of PubSubHubbub and HTTP Subscription Specification. It would be really nice if you could complement it with pointers to some real example of interfaces using one or the other approach. This could help practitioners identify is the better fit for their use case.
I don't understand the diagram.<p>The POST to /subscription line going from left to right is clear. What is the GET request below it, is that another HTTP GET requests or a the response to a POST. If it is a GET why is the arrow going from Server to Client.<p>Then the response to that GET has a 201 code but that is going from client to Server?