TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Webhooks do’s and dont’s: what we learned after integrating APIs

232 点作者 giuliano84超过 8 年前

16 条评论

bazizbaziz超过 8 年前
How do people in production handle the possibility that your service might miss a webhook notification? If you miss a notification you&#x27;ll end up with stale data and you won&#x27;t know it.<p>Slack has a retry policy for a while but will then just give up. Another webhook provider I&#x27;ve looked at says nothing at all about this sort of thing. How do folks deal with this in production systems?<p>Seems to me like the best way to address this issue is to use the webhook as a hint that you need to run some other process that guarantees you&#x27;ve got all updates.
评论 #13016465 未加载
评论 #13019145 未加载
评论 #13016432 未加载
评论 #13019458 未加载
评论 #13020641 未加载
评论 #13016718 未加载
评论 #13017176 未加载
评论 #13017260 未加载
评论 #13020739 未加载
评论 #13021512 未加载
shizcakes超过 8 年前
I think the &quot;securing webhooks&quot; section is missing some critical tips that we&#x27;ve learned in production.<p>1) Resolve the DNS of the webhook URL, and compare all returned addresses from that resolution against an IP blacklist, which includes all RFC1918 addresses, EC2 instance metadata, and any other concerning addresses.<p>2) Even though it seems like you&#x27;d want to, do NOT blindly return an unexpected response to the person configuring the webhook. Say there was an error, what the code was, etc, but returning the response body means you basically just gave someone curl with a starting point on your network (see 1 as well)<p>3) Find ways to perform other validations of those webhooks. Are the URLs garbage? Are they against someone else&#x27;s system? Create validation workflows that require initial pushes to the URL with a validation token to be entered back into your system, like validating an email address by clicking a link.
评论 #13020645 未加载
评论 #13018510 未加载
评论 #13016166 未加载
评论 #13016796 未加载
评论 #13016120 未加载
sly010超过 8 年前
Aside: Webhooks are always a pain.<p>Implementing polling is easier for both sides.<p>I routinely have to integrate with random 3rd party systems, some with no or broken webhooks, some with no API at all. It turns out for my customers (this may not be always the case) eventual consistency is more important than timelyness.<p>What I do now every time I need to sync data from a third party is I always implement some sort of pull first with idempotent logic on my side. It&#x27;s easier, and it allows me to just re-run things if something fails (e.g. network error, unexpected data in production, etc).<p>Only when that works reliably and only if required by the customer I implement a webhook, but I usually throw away most of the message and just wake up my polling worker that is otherwise polling relatively slowly.
评论 #13016951 未加载
评论 #13021118 未加载
jarcoal超过 8 年前
Sort of disagree with the send-everything-in-the-payload approach. It opens your system up to all sorts of weird edge case bugs like receiving hooks out of order which could mean stale data is considered fresh. It also means you have to care a lot more about verifying the authenticity of the request.
评论 #13016979 未加载
评论 #13017093 未加载
评论 #13016908 未加载
madamelic超过 8 年前
Also, in your documentation, please show what the webhook events will look like since developers actually want to write code and not guess at what we will get.<p><i>cough</i> Stripe. (<a href="https:&#x2F;&#x2F;stripe.com&#x2F;docs&#x2F;api#events" rel="nofollow">https:&#x2F;&#x2F;stripe.com&#x2F;docs&#x2F;api#events</a>)
评论 #13016959 未加载
评论 #13016427 未加载
misterbowfinger超过 8 年前
This is going to sound bizarre, but why do webhooks and not just an AMQP queue? I get that receiving HTTP POSTs is easier, but it just seems better to setup a publisher&#x2F;subscriber relationship. That way, if a subscriber goes down, they can always catch up. And publishers can allow messages to sit in the queue with a TTL and max_size. It seems like a win-win for everyone.
评论 #13016372 未加载
评论 #13016142 未加载
评论 #13017264 未加载
评论 #13015976 未加载
评论 #13016457 未加载
boubiyeah超过 8 年前
Webhook only makes sense if you don&#x27;t care a single bit about missing updates. If not, it&#x27;s deeply flawed.<p>A pull model (polling, long-polling, SSE, etc) is strictly superior for synchronisation. You just can&#x27;t &quot;miss&quot; updates, can restart from the beginning again and reinterpret past events in a different light, the client goes at its own pace, etc.
评论 #13019256 未加载
评论 #13018449 未加载
nimblegorilla超过 8 年前
It&#x27;s also really handy when API providers give a nice webhook UI that lets you view and resend webhooks during development.
评论 #13017929 未加载
评论 #13016125 未加载
评论 #13017931 未加载
johns超过 8 年前
I did a talk a little while back on providing a good developer experience around webhooks that covers a lot of the same topics. I wish I had a recording of it, but the slides are here: <a href="https:&#x2F;&#x2F;speakerdeck.com&#x2F;johnsheehan&#x2F;crafting-a-great-webhooks-experience-1" rel="nofollow">https:&#x2F;&#x2F;speakerdeck.com&#x2F;johnsheehan&#x2F;crafting-a-great-webhook...</a><p>Edit: found the video <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=xc5ezyJjz1k&amp;feature=youtu.be&amp;t=1266" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=xc5ezyJjz1k&amp;feature=youtu.be...</a>
simo9000超过 8 年前
I&#x27;d like to follow up on the statement that the OpenAPI tools do not support webhooks. This is slated to change in an upcoming version of the OpenAPI-specification. Check out <a href="https:&#x2F;&#x2F;github.com&#x2F;OAI&#x2F;OpenAPI-Specification&#x2F;pull&#x2F;763" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;OAI&#x2F;OpenAPI-Specification&#x2F;pull&#x2F;763</a> to see details. As soon as this is released, it only be a matter of time before Swagger and the rest support webhooks.
z3t4超过 8 年前
To be fully client based (serverless) you need a middle-man for web-hooks. Websockets are a better alternative for stand-alone web clients. There are also &quot;push notifications&quot; via web workers but they are vendor dependent.
arxpoetica超过 8 年前
Honest question. Why webhooks over something like push&#x2F;pull handshaked socket?
评论 #13016406 未加载
评论 #13016417 未加载
intellent超过 8 年前
What I am most interested in is how to test&#x2F;debug webhooks during development.<p>How do I tell webhook providers to send test notifications to my local development instance without tampering with the production setup on both sides?
评论 #13024426 未加载
Animats超过 8 年前
So &quot;push technology&quot; is called &quot;webhooks&quot; now?<p>How does this all integrate with HTTP 2? Can you get your notifications over a channel you already have open for other reasons?
评论 #13017579 未加载
mosselman超过 8 年前
It would have been interesting to read about tests for web-hooks. How do you do integration testing for example?
评论 #13019725 未加载
g105b超过 8 年前
Apostroph&#x27;ed.