Voorstellen t.b.v. de ZGW API performance verbeteringen

[joeribekker]

Hieronder komen voorstellen voor de ZGW APIs

[sergei-maertens]

Uit mijn gist die eerder opgesteld was. Ik heb nog wat gedachten hierbij die ik maandag ga aanvullen.

---

Optimizing the ZGW API's for reading ⚡

Below is a proposal and example of how the ZGW API's (2.0?) can be optimized for reading
and displaying information obtained from the APIs, even across API boundaries.

Observed problem(s)

• High complexity on the consumer side: fetching data, response contains pointers to
  more data to fetch for a complete picture of the information
• Data + "metadata" are in separate APIs, but required for a complete picture of the
  information
• Performance is bad because of the amount of API calls needed and inherent sequential
  nature, removing potential to perform requests in parallel

Example request and response

As an example, we can use the (common) case of retrieving a list of ZAAKen from the
Zaken API. To display case information, we are also interested in the (current) status
and ZAAKTYPE omschrijving, requiring access to the catalogi API.

Variant 1: inclusions mechanism

GET /api/v2/zaken?include=status,zaaktype HTTP/1.1

Host: zaken-api.vng.cloud
Authorization: Bearer abcdefg.ijkl.mnop

Note the include querystring parameter, which in this example asks to "expand" the
STATUS and ZAAKTYPE resources.

A response would look like this:

{
    "count": 2,
    "next": null,
    "previous": null,
    "data": [
        {
            "url": "https://zaken-api.vng.cloud/api/v2/zaken/d0e7c478",
            "zaaktype": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
            "identificatie": "zaak-001",
            "omschrijving": "Voorbeeldzaak 1",
            "status": "https://zaken-api.vng.cloud/api/v2/statussen/2e4eeaa5"
        },
        {
            "url": "https://zaken-api.vng.cloud/api/v2/zaken/05da0e11",
            "zaaktype": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
            "identificatie": "zaak-002",
            "omschrijving": "Voorbeeldzaak 2",
            "status": "https://zaken-api.vng.cloud/api/v2/statussen/8a564101"
        }
    ],
    "inclusions": {
        "zaken.status": [
            {
                "uuid": "2e4eeaa5",
                "url": "https://zaken-api.vng.cloud/api/v2/statussen/2e4eeaa5",
                "zaak": "https://zaken-api.vng.cloud/api/v2/zaken/d0e7c478",
                "statustype": "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                "datumStatusGezet": "2022-02-24T14:15:22Z",
                "statustoelichting": ""
            },
            {
                "uuid": "8a564101",
                "url": "https://zaken-api.vng.cloud/api/v2/statussen/8a564101",
                "zaak": "https://zaken-api.vng.cloud/api/v2/zaken/05da0e11",
                "statustype": "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                "datumStatusGezet": "2022-01-23T08:43:00Z",
                "statustoelichting": ""
            }
        ],
        "catalogi.zaaktype": [
            {
                "url": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
                "catalogus": "https://catalogi-api.vng.cloud/api/v2/catalogi/4e851f9d",
                "identificatie": "456",
                "omschrijving": "Zaaktype 456",
                "statustypen": [
                    "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                    "https://catalogi-api.vng.cloud/api/v2/statustypen/7e33d7ac",
                ],
            }
        ],
    }
}

The response now has an enveloppe with the regular pagination parameters, and the
responses as-they-are-in-v1 under the data key. New is the inclusions key, which
contains the data from the "other resource" endpoints keyed by resource name, always
as a collection.

In this example, both cases in the result list have the same zaaktype, so the included
zaaktype in the inclusions is present only once. The inclusions mechanism
performs de-duplication.

Note also that to obtain the zaaktype information, an API boundary must be crossed -
the Zaken API has to retrieve this data from the Catalogi API. It already needs this
access to perform input-validation, so the idea is not too wild.

Variant 2: deep inclusions

The second variant expands on the first one by requesting nested inclusions. In variant
2, we still have to look up the status.statustype in the Catalogi API. This can be
retrieved in a single call (for the consumer), with optimized retrieval implemented in
the Zaken API.

GET /api/v2/zaken?include=status,status.statustype,zaaktype HTTP/1.1
Host: zaken-api.vng.cloud
Authorization: Bearer abcdefg.ijkl.mnop

Response:

{
    "count": 2,
    "next": null,
    "previous": null,
    "data": [
        {
            "url": "https://zaken-api.vng.cloud/api/v2/zaken/d0e7c478",
            "zaaktype": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
            "identificatie": "zaak-001",
            "omschrijving": "Voorbeeldzaak 1",
            "status": "https://zaken-api.vng.cloud/api/v2/statussen/2e4eeaa5"
        },
        {
            "url": "https://zaken-api.vng.cloud/api/v2/zaken/05da0e11",
            "zaaktype": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
            "identificatie": "zaak-002",
            "omschrijving": "Voorbeeldzaak 2",
            "status": "https://zaken-api.vng.cloud/api/v2/statussen/8a564101"
        }
    ],
    "inclusions": {
        "zaken.status": [
            {
                "uuid": "2e4eeaa5",
                "url": "https://zaken-api.vng.cloud/api/v2/statussen/2e4eeaa5",
                "zaak": "https://zaken-api.vng.cloud/api/v2/zaken/d0e7c478",
                "statustype": "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                "datumStatusGezet": "2022-02-24T14:15:22Z",
                "statustoelichting": ""
            },
            {
                "uuid": "8a564101",
                "url": "https://zaken-api.vng.cloud/api/v2/statussen/8a564101",
                "zaak": "https://zaken-api.vng.cloud/api/v2/zaken/05da0e11",
                "statustype": "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                "datumStatusGezet": "2022-01-23T08:43:00Z",
                "statustoelichting": ""
            }
        ],
        "catalogi.zaaktype": [
            {
                "url": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
                "catalogus": "https://catalogi-api.vng.cloud/api/v2/catalogi/4e851f9d",
                "identificatie": "456",
                "omschrijving": "Zaaktype 456",
                "statustypen": [
                    "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                    "https://catalogi-api.vng.cloud/api/v2/statustypen/7e33d7ac",
                ],
            }
        ],
        "catalogi.statustype": [
            {
                "url": "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                "omschrijving": "Aanvraag ontvangen",
                "zaaktype": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
                "volgNummer": 1,
                "isEindstatus": false
            }
        ]
    }
}

The response gained just a little bit extra data compared to Variant 1: the inclusion
catalogi.statustype was added. And since both statusses included before were of the
same statustype, this information was de-duped again.

Theoretically, if you were to also request the inclusion status.statustype.zaaktype,
nothing would change in the response, since the zaaktypen were already included via
the zaaktype inclusion.

Variant 3

There could be room for an ?include=* mechanism to load all inclusions. The response
keeps the same shape.

Considerations worth mentioning

The include mechanism works for resources across APIs, but doesn't have to.

Implementations such as Open Zaak that have all the data in a single database can
effectively query the data from the database. If (part of) the data lives in an
external API (e.g. external catalogi/documenten API), the Zaken API is still able to
retrieve this data by making API calls to those services in the most optimal way.

This moves the data-fetching from the consumer to the provider side, reducing complexity
and(HTTP) overhead for clients.

Challenge: forwarding the credentials/permissions to the external APIs to ensure the
Zaken API does not leak data not visible for the client.

The include mechanism is granular enough for (advanced) clients

The dotted-path lookup mechanism lets the client decide how deep the data should be
looked up to be included. They can opt to let the inclusion generate a de-duplicated
list of related data, which the client then uses to make the most efficient follow-up
call, possibly specyifing inclusions by itself again.

Potential for caching at provider side

When looking up relations across API boundaries, a network call overhead is incurred.
Some data (especially the Catalogi API!) is very suitable for caching with long TTLs,
as the data is frozen after publication. This makes it suitable to keep this data in
a cache close to the Zaken API, making it possible to reduce the amount of network
calls needed and thereby improving performance.

The Autorisaties API can be queried by a Zaken API to determine which of that (cached)
data is accessible by the client.

Tried and tested mechanism

The mechanism is in production use and implemented in a library:
https://github.com/isprojects/djangorestframework-inclusions

While designing this pattern, ideas have been borrowed from HAL, GraphQL and json-api.

Other solutions considered

HAL

Standard proposal has been in limbo for a long time, and is considered too verbose,
while the proposed approach only requires the top level data and inclusions
enveloppe keys. There is no repeated nested structure, instead the inclusions are
hoisted from an arbitrary nesting level to the top-level inclusions key.

GraphQL

GraphQL is very suitable for clients who want to control which data is returned in
the response and combats the problem that "a lot" of useless data is returned with
REST responses, thereby reducing the bandwidth needed.

The inclusions mechanism partially tackles this - it stays true to RESTful principles
(deliberately!) to guarantee a boring but predictable API. Additionally, with collections
having the same referenced data (zaak.zaaktype identical), there is still overhead by
duplicated data caused by the denormalization. The inclusions mechanism de-duplicates
this and a single resource only appears once in the response body.

json-api

json-api is a strict HATEOAS implementation and defines a complex, recursive schema for
dealing with related data, arguably destroying a lot of the simplicity of simple JSON
responses.

The inclusions mechanism is heavily inspired by json-api and aims to be a more
light-weight version.

?expand parameter

It helps to reduce network calls needing to be made, but in the case of (heavily)
normalized source data, this leads to request body overhead because of duplicated
included representations.

The inclusions mechanism combats this by hoisting the "expanded" resources and
de-duplicating them in the process.

---

Edits/amendments 21-03-2022

Boundaries of inclusions

We cannot expect the ZGW API's to "know the entire world", by which I mean they cannot possibly be aware or be updated all the time for API/resource definitions in other domains that may be tangentially related. Think of the BRP, but also BAG API or any other API/resource that may be connect to a "ZAAK".

In my opinion, the boundaries for inclusions are limited to the domain of the ZGW API's. This means that Zaken API can include Zaaktypen and related resources, but not a "Natuurlijk persoon" who happens to be the "initiator" of the "ZAAK". We can even make this more specific by tying it to the performed input validations. If a resource needs to be fetchable to validate it, then it can be included, otherwise not.

For those resources to further simplify client development, you could consider a convenience API that sits on top of the ZGW API's, but I doubt that this will be easy to standardize and define completely upfront. Those API's are very application dependent, and you don't want to bloat them and cause cognitive and maintenance overload with stuff of other domains that is not even relevant. If you are only using 10% of an API definition, I'm afraid that API definition is too big.

I'm also not confident that you can specify a filtering/searching API that can cover all particular edge cases needed, so I'm still in favour of leaving that to the client application and domain.

[joeribekker]

Nog een alternatief:

Breid de GET uit met alle gerelateerde resources binnen dezelfde API voor het hoofdobject. Dit stelt ons in staat om bijvoorbeeld bij een GET /zaken/<uuid> in één keer alle informatie terug te geven (inline) wat zich in deze API bevind met betrekking tot deze zaak (zaak, resultaat, status, zaakinformatieobjecten, eigenschappen, etc.).

Deze change kan zelfs backwards compatibel worden gedaan en zou een hoop calls schelen.

Eigenlijk hanteer je dan "Haal Centraal" op de hoofd objecten: Zaak in Zaken API, Informatieobject in Documenten API, en de Catalogi API zijn het er 3: Zaaktype, Informatieobjecttype en Besluittype.

[jjansenvr]

Goed idee!, heb ooit een api gemaakt waarbij het &expand in de uri alle onderliggende objecten inline meegaf ipv als link.

Nadeel ligt bij caching, als je dat netjes neerzet zouden alleen de gewijzigde objecten over de lijn gaan en in dit geval is het object ineens een zaak met al zijn subobjecten

Om de migratie tussen ZDS en ZGW eenvoudiger te maken zou een POST van een complete zaak ook erg kunnen helpen, nu is het bijna onmogelijk om complete verwerking van een ZDS zaak in de api's te garanderen

[EduardWitteveen]

Een voorbeeld uit de praktijk valt te vinden op: Sudwest-Fryslan/OpenZaakBrug#323 (met tijdsduur erbij)

[sergei-maertens]

Ik heb dit op OpenAPI 3.0 niveau uitgewerkt in de Zaken API, dit geeft een voorbeeld hoe de API documentatie er dus uit ziet met inclusions:

ReDoc: https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/maykinmedia/zaken-api/feature/poc-inclusions-api-spec/src/openapi.yaml#tag/zaken

Aandachtspunten:

• de query parameter include bevat alle mogelijke inclusions en specifieert zelfs het serialization format in OAS (?include=zaaktype,status,status.statustype). Dit is iets duidelijker in Swagger ipv ReDoc.
• De OpenAPI zelf verwijst naar resource schemas in de andere APIs. We hoeven dus de definities niet te dupliceren. Dit laat je ook toe om tegelijk naar de v1.0 en v1.1 van de Catalogi API te verwijzen wat de compatibilteit hiermee uitdrukt! Klik hiervoor onder inclusions het schema voor catalogi:zaaktype open om dit te zien.

Screenshots:

OAS code: https://github.com/maykinmedia/zaken-api/blob/feature/poc-inclusions-api-spec/src/openapi.yaml#L3241

[sergei-maertens]

Ik was nog wat verder aan het denken over het HAL voorbeeld en het zit me nog steeds niet lekker om dat te gaan toepassen.

1. Ik denk dat het uberhaupt niet kan werken met cyclische referenties - bijvoorbeeld twee gerelateerde zaken die naar elkaar verwijzen. Als je dan zou opvragen om ?expand=gerelateerdeZaken, dan krijg je geneste _embedded objecten die oneindig doorgaan. Je kan niet consequent de expand actie opnemen. Dat kan met inclusions wel omdat de-duplicatie en hoisting plaats vindt.
2. De HAL specificatie was nooit bedoeld voor een dergelijk mechanisme. De meest recente draft (https://datatracker.ietf.org/doc/html/draft-kelly-json-hal-08) vermeld niet eens query string parameters of een mechanisme om aan embedded resources te komen. De draft zegt letterlijk "HAL's conventions result in a uniform interface for serving and consuming hypermedia, enabling the creation of general-purpose libraries that can be re-used on any API utilising HAL.". HAL toepassen om dit performance probleem op te lossen is een hamer gebruiken om een schroef in te slaan. It probably sort-of-works, maar het was er nooit voor bedoeld.
3. De populariteit of beschikbaarheid moet uiteraard ook gezien worden in de context van het doel. Mijn eerste indruk is dat de libraries vooral met het formaat HAL omgaan (omdat of de server het afdwingt, of iemand ergens ooit besloten heeft dat HAL moet gebruikt worden), maar een echte HAL client die navigeert met de _links die geëxposed worden heb ik nog niet gezien. En precies dat laatste is het oorspronkelijke doel van HAL.
4. Het wordt als feit gesteld dat HAL een "industriestandaard" is om te counteren dat HAL slechts een draft-standaard is. Echter, bij grote partijen die APIs aanbieden zoals Github, bol.com, Microsoft Graph API, Zalando, Facebook Graph API kan ik niet eens de optie terugvinden om HAL te gebruiken. Deze partijen kan je wel echt grote spelers in de industrie noemen. Zalando is overigens best vocaal over HATEOAS en hoe praktisch onbruikbaar het is.

Ik ben overigens ook erg benieuwd naar de (inhoudelijke) motivering om HAL wél in andere APIs toe te passen, en dan niet een makkelijk argument als "dat staat voorgeschreven op plaats X" - dan wil ik ook weten waarom dat staat voorgeschreven.

[HenriKorver]

Last but not least... Bij deze een voorstel waarin het beste uit twee werelden wordt gecombineerd. Namelijk een oplossing waarin de inclusions in-line worden toegevoegd net zoals bij HAL maar dan met plain json syntax die volledig backwards compatible is met de huidige syntax van de ZGW-berichten. Voor de backwards compatibility is ook het top-container element "data" hernoemd naar de originele naam "results".

GET /api/v2/zaken?expand=zaaktype,status HTTP/1.1
Host: zaken-api.vng.cloud

{
    "count": 2,
    "next": null,
    "previous": null,
    "results": [
        {
            "url": "https://zaken-api.vng.cloud/api/v2/zaken/d0e7c478",
            "zaaktype": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
            "identificatie": "zaak-001",
            "omschrijving": "Voorbeeldzaak 1",
            "status": "https://zaken-api.vng.cloud/api/v2/statussen/2e4eeaa5",
            "_expand": {
                "zaaktype": {
                    "url": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
                    "catalogus": "https://catalogi-api.vng.cloud/api/v2/catalogi/4e851f9d",
                    "identificatie": "456",
                    "omschrijving": "Zaaktype 456",
                    "statustypen": [
                        "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                        "https://catalogi-api.vng.cloud/api/v2/statustypen/7e33d7ac"
                    ]
                },
                "status": {
                    "uuid": "2e4eeaa5",
                    "url": "https://zaken-api.vng.cloud/api/v2/statussen/2e4eeaa5",
                    "zaak": "https://zaken-api.vng.cloud/api/v2/zaken/d0e7c478",
                    "statustype": "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                    "datumStatusGezet": "2022-02-24T14:15:22Z",
                    "statustoelichting": ""
                }
            }
        },
        {
            "url": "https://zaken-api.vng.cloud/api/v2/zaken/05da0e11",
            "zaaktype": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
            "identificatie": "zaak-002",
            "omschrijving": "Voorbeeldzaak 2",
            "status": "https://zaken-api.vng.cloud/api/v2/statussen/8a564101",
            "_expand": {
                "zaaktype": {
                    "url": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
                    "catalogus": "https://catalogi-api.vng.cloud/api/v2/catalogi/4e851f9d",
                    "identificatie": "456",
                    "omschrijving": "Zaaktype 456",
                    "statustypen": [
                        "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                        "https://catalogi-api.vng.cloud/api/v2/statustypen/7e33d7ac"
                    ]
                },
                "status": {
                    "uuid": "8a564101",
                    "url": "https://zaken-api.vng.cloud/api/v2/statussen/8a564101",
                    "zaak": "https://zaken-api.vng.cloud/api/v2/zaken/05da0e11",
                    "statustype": "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                    "datumStatusGezet": "2022-01-23T08:43:00Z",
                    "statustoelichting": ""
                }
            }
        }
    ]
}

Voordelen:

• Volledig backwards compatible met huidige syntax van de ZGW-berichten (eerdere oplossing is dat niet).
• Clients kunnen de includes makkelijk resolven omdat ze in-line op de goede plek staan.
• Geen gedoe met paginering. De include-set hoeft niet opnieuw berekend te worden bij opvraging van een nieuwe pagina.

Nadelen:

• Geen ontdubbeling van includes in het response bericht. Echter dat is niet het performance probleem. Het gaat om de ontdubbeling van de calls en dat gebeurt natuurlijk wel.
• Mogelijk een probleem met cyclische verwijzingen. Kan waarschijnlijk worden opgelost door de recursie te breken met het zetten van een vlaggetje op de server.

Deep expand

Deze oplossing werkt ook met geneste expands (deep expand) waarbij binnen expand recursief ook weer gelinkte resources worden opgenomen.

GET /api/v2/zaken?expand=zaaktype,status,status.statustype HTTP/1.1
Host: zaken-api.vng.cloud

Response:

{
    "count": 2,
    "next": null,
    "previous": null,
    "results": [
        {
            "url": "https://zaken-api.vng.cloud/api/v2/zaken/d0e7c478",
            "zaaktype": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
            "identificatie": "zaak-001",
            "omschrijving": "Voorbeeldzaak 1",
            "status": "https://zaken-api.vng.cloud/api/v2/statussen/2e4eeaa5",
            "_expand": {
                "zaaktype": {
                    "url": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
                    "catalogus": "https://catalogi-api.vng.cloud/api/v2/catalogi/4e851f9d",
                    "identificatie": "456",
                    "omschrijving": "Zaaktype 456",
                    "statustypen": [
                        "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                        "https://catalogi-api.vng.cloud/api/v2/statustypen/7e33d7ac"
                    ]
                },
                "status": {
                    "uuid": "2e4eeaa5",
                    "url": "https://zaken-api.vng.cloud/api/v2/statussen/2e4eeaa5",
                    "zaak": "https://zaken-api.vng.cloud/api/v2/zaken/d0e7c478",
                    "statustype": "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                    "datumStatusGezet": "2022-02-24T14:15:22Z",
                    "statustoelichting": "",
                    "_expand": {
                        "statustype": {
                            "url": "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                            "omschrijving": "Aanvraag ontvangen",
                            "zaaktype": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
                            "volgNummer": 1,
                            "isEindstatus": false
                        }
                    }
                }
            }
        },
        {
            "url": "https://zaken-api.vng.cloud/api/v2/zaken/05da0e11",
            "zaaktype": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
            "identificatie": "zaak-002",
            "omschrijving": "Voorbeeldzaak 2",
            "status": "https://zaken-api.vng.cloud/api/v2/statussen/8a564101",
            "_expand": {
                "zaaktype": {
                    "url": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
                    "catalogus": "https://catalogi-api.vng.cloud/api/v2/catalogi/4e851f9d",
                    "identificatie": "456",
                    "omschrijving": "Zaaktype 456",
                    "statustypen": [
                        "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                        "https://catalogi-api.vng.cloud/api/v2/statustypen/7e33d7ac"
                    ]
                },
                "status": {
                    "uuid": "8a564101",
                    "url": "https://zaken-api.vng.cloud/api/v2/statussen/8a564101",
                    "zaak": "https://zaken-api.vng.cloud/api/v2/zaken/05da0e11",
                    "statustype": "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                    "datumStatusGezet": "2022-01-23T08:43:00Z",
                    "statustoelichting": "",
                    "_expand": {
                        "statustype": {
                            "url": "https://catalogi-api.vng.cloud/api/v2/statustypen/0e670d281",
                            "omschrijving": "Aanvraag ontvangen",
                            "zaaktype": "https://catalogi-api.vng.cloud/api/v2/zaaktypen/d2feda7f",
                            "volgNummer": 1,
                            "isEindstatus": false
                        }
                    }
                }
            }
        }
    ]
}

Foutafhandeling
Onderstaand de error-message in geval het zaaktype niet geëxpandeerd kon worden omdat bijvoorbeeld de Catalogi API down was.

{
    "type": "https://zaken-api.vng.cloud/ref/fouten/ValidationError/",
    "code": "expansion-failure",
    "title": "Expansion failure",
    "status": 502,
    "detail": "502 Bad Gateway. This error response means that the server, while working as a gateway to get a response needed to handle the request, got an invalid response.",
    "instance": "urn:uuid:f93e98a8-9793-40b9-ad71-7b63d986ce6c",
    "invalidParams": [
        {
            "name": "zaaktype",
            "code": "no_expand",
            "reason": "Dit veld kon niet geëxpandeerd worden."
        }
    ]
}