-
Notifications
You must be signed in to change notification settings - Fork 6
Description
Currently, when you're creating a nested resource such as a zaakeigenschap, you need to duplicate some information in the request body and URL:
Given a Zaak with UUID 5939c17e-3f2e-45f4-bfb3-67943bc35112
, the request to create a zaakeigenschap looks like:
POST /api/v1/zaken/5939c17e-3f2e-45f4-bfb3-67943bc35112/zaakeigenschappen HTTP/1.1
Content-Type: application/json
{
"zaak": "https://example.com/api/v1/zaken/5939c17e-3f2e-45f4-bfb3-67943bc35112",
"eigenschap": "<url to eigenschap in catalogi API>",
"waarde": "1234"
}
As you can see, there's no need to specify the zaak in the body, because the UUID is already present in the URL you're POST-ing to. This snuck in because we do want to include that field in the read operation of eigenschappen and because of limitations at the time of the library used for nested resources.
These limitations have been resolved though, and it would make more sense to support this set of requests and responses:
POST /api/v1/zaken/5939c17e-3f2e-45f4-bfb3-67943bc35112/zaakeigenschappen HTTP/1.1
Content-Type: application/json
{
"eigenschap": "<url to eigenschap in catalogi API>",
"waarde": "1234"
}
Response:
{
"zaak": "https://example.com/api/v1/zaken/5939c17e-3f2e-45f4-bfb3-67943bc35112",
"eigenschap": "<url to eigenschap in catalogi API>",
"naam": "voorbeeld",
"waarde": "1234"
}
Currently labeling this as breaking change for 2.0, but in reality, this wouldn't be a breaking change IF servers ignore any excess body parameters (which I expect the reference implementation to do).