Webhooks support #291
Merged
Webhooks support #291
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## main #291 +/- ##
==========================================
+ Coverage 95.51% 96.04% +0.52%
==========================================
Files 20 21 +1
Lines 937 1138 +201
==========================================
+ Hits 895 1093 +198
- Misses 42 45 +3
|
|
Hi @mesozoic - thanks for doing this! I took a quick skim and it looks good to me. No imminent changes and I think it's smart to ensure additional fields do not break types/etc as the deprecation guidelines note:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This branch introduces models representing the webhooks API along with methods for validating notifications and for retrieving new webhook payloads. It adds the following methods and classes to the public API:
Base.add_webhook(url, spec)Base.webhooks()Base.webhook(id)models.WebhookNotificationmodels.WebhookNotification.from_request(body, header, secret)models.Webhookmodels.Webhook.{enable,disable}_notifications()models.Webhook.extend_expiration()models.Webhook.payloads(cursor=1)models.WebhookPayloadThe major design decision here is to not return plain old
dictdata structures from the API, and instead to parse them into nested pydantic data models with type annotations, usingextra = "ignore"so that it doesn't crash if Airtable adds more fields in the future.The advantage of this approach is a cleaner API and more assistance for developers who use type-aware IDEs; the disadvantage is that any new fields which Airtable adds to their API in the future will require a patch release to fully support. I've worked around this by adding a private attribute called
_rawto every model which will be the API payload which generated the model. In a pinch, a developer could access that directly if it contains anything our models don't recognize.Tagging a few folks for input: