search

coyote-team / coyote-drupal

0 stars 0 forks source link

Support webhook updates #9

Open jkva opened 2 years ago

jkva commented 2 years ago

When a resource on the Coyote side is managed using a webhook which posts to a Drupal website running the module, the module should expose an API endpoint which can receive Coyote's POST payloads. When a valid resource update comes through, this should cause the module to update its own information about the resource.

jkva commented 2 years ago

Some work for this has already been done in https://github.com/coyote-team/coyote-drupal-8/blob/develop/src/Controller/RestApiController.php

jkva commented 1 year ago

@catorghans given our conversation a while ago on the webhook payload I created issue https://github.com/coyote-team/coyote/issues/659 on the Coyote server side.

Having looked into its implementation, it actually makes sense - when a resource or a related representation gets modified, the server posts the entirety of the modified resource model towards the webhook, including all its representations. This means that when a resource's name gets modified, this also happens. There is (currently) no metadata in this payload regarding what change triggered the webhook call.

On the Drupal-side, the only representation we're really interested in is the "top representation by metum", which is already handled by the Rest API hook handler. Given this, I would posit that the response to a webhook call can be idempotent: the hook code takes the top representation value — content notwithstanding — and updates it locally.

For efficiency's sake there could be a string compare (and accompanying info log message) since that would save a potential cache invalidation. What do you think?

jkva commented 1 year ago

This item is currently blocked on https://github.com/coyote-team/coyote/issues/659. For now, the module will grab the top representation for its metum from within the serialised resource payload that gets posted to the module callback.