Templated webhooks

[Jeff Lindsay]

I started a new thread since nobody else did.

Mike,

I'm starting to better understand. So you want people implementing evented APIs to directly implement "templated webhooks"?

-jeff

On Wed, Nov 28, 2012 at 6:42 PM, Mike Kelly <mikeke...@gmail.com> wrote:

I'm pretty sure I understand the X-Callback proposal.. you are
dynamically specifying the method and the URL (i.e. the request line)
of the callback request.

Cheers,
M

On Thu, Nov 29, 2012 at 2:32 AM, Jeff Lindsay <prog...@gmail.com> wrote:
> Mike Kelly,
>
> I think you're also confusing what I'm talking about with the payload of
> callbacks. Maybe you can redescribe what you think I'm talking about so I
> can try to make it more clear? Or maybe it would help me better see that I'm
> just terrible at explaining anything.
>
> -jeff
>
>
> On Wed, Nov 28, 2012 at 5:27 PM, Mike Kelly <mikeke...@gmail.com> wrote:
>>
>> On Thu, Nov 29, 2012 at 1:18 AM, Jeff Lindsay <prog...@gmail.com> wrote:
>> > Evented APIs should just be web APIs with callbacks, not an API and some
>> > completely separate mechanism that looks nothing like the rest of the
>> > API.
>> > As somebody that designs APIs I would imagine you could appreciate that.
>>
>> I don't think I understand what you are getting at here, please could
>> you expand?
>>
>> > Working in the header space means you stay out of the way. You can
>> > include
>> > callbacks in requests for existing resources people are already
>> > modeling. If
>> > they're modeling callbacks, they can do it however they like and still
>> > have
>> > a standard way to talk about them. This is important when it comes to
>> > the
>> > protocols we *build on top of this*.
>>
>> afaik, that is not the typical usage of webhooks.. in most cases the
>> callback is configured/specified up-front (either via an API or some
>> GUI).
>>
>> Cheers,
>> M
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "WebHooks" group.
>> To post to this group, send email to webh...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> webhooks+u...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/webhooks?hl=en.
>>
>
>
>
> --
> Jeff Lindsay
> http://progrium.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "WebHooks" group.
> To post to this group, send email to webh...@googlegroups.com.
> To unsubscribe from this group, send email to
> webhooks+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/webhooks?hl=en.



--

Mike

http://twitter.com/mikekelly85
http://github.com/mikekelly
http://linkedin.com/in/mikekelly123

--
You received this message because you are subscribed to the Google Groups "WebHooks" group.
To post to this group, send email to webh...@googlegroups.com.
To unsubscribe from this group, send email to webhooks+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/webhooks?hl=en.

--
Jeff Lindsay
http://progrium.com

[Jeff Lindsay]

After thinking about it more, it seems like a service like webgun could just provide templated webhooks for anybody and nobody has to directly implement templated webhooks. I'm still confused by webgun and what it is right now but I'm just envisioning you post your template to webgun, but also the URL that webgun would register a callback with. You become a sort of proxy translator service. But in that model, you're completely orthogonal and that would only work if there was a standard for registering more general webhooks (most likely with something like HTTP Subscriptions). 

[Mike Kelly]

I think the issue might be that the article really introduces 2 things
in one go:

1. webgun as an infrastructure service that app developers can use to
avoid implementing and managing it themselves
2. templated webhooks

You could write your own infrastructure for storing your clients
templates and generating the callback with them on particular events.
There is nothing tying the template format used in the article to
webgun. I actually intended to specify and register the format demo'd
as a media type.

Templated webhooks just add much more dynamism to the callback request
that gets generated. So rather than your customers specifying only the
URL where the requests should land, they also specify the headers and
body of that request too. This then allows the potential for customers
to integrate your app with any service they so desire, without you
having to lift a finger you can think about that as "serendipitous
integration".

does that clarify anything? Sounds like I need to rework that article!

Cheers,
M

[Jeff Lindsay]

Yeah I guess I'm confused more about webgun and what it does. But I understand templated webhooks and appreciate it in the ecosystem. I think they'd provide much more value if something like mailgun managed the templates and transformation for you. Maybe that's what it does? 

Anyway, cool project. There are definitely a number of approaches to this specific problem. That's why I've avoided including it in discussions for standards. But if for some reason anything proposed gets in the way, definitely say something. From what I understand, so far there's nothing that's been proposed that would really change anything -- just some groundwork for a common primitive for some upcoming protocols I've been working on with people.