Webhook Clarifications

[David Celis]

Parts of the webhook documentation are confusing me a bit, namely around the actions and subactions. I think at this point (after some searching) I only have a couple of questions right now.

If I get a webhook request with:

  {

    "attribute": "beer",

    "action": "edit", // It WOULD be "edit" in this case, right?

    "attributeId: "aE45C",

    "subAction": "brewery-edit"

  }

So with this request, is it possible that there would also be changes to the beer itself since the action is "edit"? Or are webhooks restricted to a single event (i.e. if there were also changes to the beer, there would be another webhook request without a subAction)?

Also, presumably there would be another webhook with an "attribute" of "brewery" and an "action" of "edit", yeah?

I guess my biggest question here is: is there any reason to pay attention to a subAction of "brewery-edit" when the Brewery has its own webhook? Presumably, I could discard the "brewery-edit" subAction requests and just act on the webhook that comes in specifically for the brewery.

[Jason Austin]

David,

If you get a hook with the action of "edit" and a subAction is set, then it's the relationship that has been edited, not the main attribute.  In the case you sent, it means that the relationship between beer and brewery was edited, not the beer itself.

Your assumption of getting a hook with attribute of brewery is correct as well.

The reason that you would get both of these is because we allow people to only signup for notifications on a single attribute (beer, brewery, event, guild, or location) as well as signup for all of them.  If you only were subscribed to brewery updates, you wouldn't get the one about the beer.  Make sense?

- Jason

--
You received this message because you are subscribed to the Google Groups "Brewery DB API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brewerydb-ap...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jason Austin

Co-Founder - PintLabs L.L.C.

ja...@pintlabs.com

http://www.pintlabs.com

http://www.brewerydb.com

http://www.brewerymap.com

[David Celis]

Yeah I forgot about the single endpoint stuff, makes sense. Thanks for the clarification!

[Jason Austin]

No problem.  Let us know if you have any more questions.

Cheers!

Jason

[David Celis]

Alright, got another question for you. In trying to keep the logic for various sub-actions as separate as possible, I'm running into a potential scenario that is causing me some fear.

Is it possible I'll get a webhook for, say, an action of "insert" with an attribute of "beer" before I have its brewery locally? For example: when you guys approve a new brewery that gets beers added to it, do all of those webhooks fire at once and is it possible I'll get a webhook or two for the beer first? Do I need to make sure, in my beer webhook code, to create the brewery if it doesn't exist locally?

— David

[Jason Austin]

While it's possible, it's not probable, at least from the BreweryDB end.  We process the changes first in, first out.  So in theory, you would get the brewery first, then beers later.  However, you probably should not count on that as there may be situations that occur outside our control, like say your host is down for some amount of time and you miss some updates.

We have a solution in place to mitigate that kind of chance, but we're not quite done testing it for production yet.  We are creating an endpoint that can be queried to get all the changes over x amount of time, so if your web hook code goes offline, you don't have to reset your entire local database, you can just query this endpoint and it will give you all the changes that web hooks would have pushed to you.

- Jason

[Steven Harman]

We've taken the approach that the job that is updating the Beer info will fail, and be automatically retried later (w/exponential back off). So eventually the job to fetch the brewery will fire and succeed, and then the next retry of the Beer will work.

-- 

Steven Harman

http://brewdega.com