Hoe hou je je abonnement in stand bij een nieuwe versie van een zaaktype?

[alextreme]

DH Taiga 420

Hoe hou je je abonnement in stand bij een nieuwe versie van een zaaktype? Meer een open vraag, hier heb ik eigenlijk geen antwoord op (behalve opnieuw aanmaken).

[joeribekker]

Refinement: This sounds like a problem indeed.

We either need to 1) rework the whole "use uuid" idea (not likely to happen, seeing its even part of the NL API strategy) or 2) the Catalog API should not change the uuid when the version changes (much desired from me personally)

Zaaktypes:

• api/v1/zaaktypen/abc123 (version 1 of zaaktype foo)
• api/v1/zaaktypen/efd567 (version 2 of zaaktype foo)

Objecttypes:

• api/v1/objecttype/aaa111 (latest version of objecttype bar)
• api/v1/objecttype/aaa111/version/1 (version 1 of objecttype bar)
• api/v1/objecttype/aaa111/version/2 (version 2 of objecttype bar)

So, we should maybe adopt the Objecttypes versioning scheme so you can subscribe to the "latest" version URL.

[alextreme]

Related Gemma zaken issues:

VNG-Realisatie/gemma-zaken#1851
VNG-Realisatie/gemma-zaken#1857

Afaik this was (and not anymore) considered tackled in Catalogi API v1.3 (Historie model)

https://vng-realisatie.github.io/gemma-zaken/standaard/catalogi/release_notes.html

[joeribekker]

If you can find there if UUIDs are no longer unique, show me a screenshot :)

[alextreme]

@joeribekker see the details from the Historiemodel Catalogi API, where non-unique UUIDs were implied:

https://michielverhoef.github.io/gemma-zaken/standaard/catalogi/#ztc-013

But this was reverted as far as I know. It may cause our developer-heads to explode and have too many consequences throughout the codebase but from a API backwards-compatibility sense it made sense in my eyes

[joeribekker]

Refinement: We could:

1. Change Notification API to save subscriptions based on zaaktype identificatie instead of uuid AND change the catalog API to sent this identificatie as well AND modify the Zaken API to sent/use the identificatie of the zaaktype (lots of odd changes in the API spec)
2. Monitor new zaaktypes, check the identificatie of this zaaktype, check all zaaktypes that have the same identificatie, get their uuids, then update the notification subscriptions (does not require changes in the standard, but feels very clunky)
3. Allow subscriptions on a catalog, so you will get all notifications for all zaaktypes in that catalog thus also the new versions. This requires

The only way to change this without changing the standard is with option 2 but we highly recommend changing the API standard with this scenario in mind.