You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.1Content-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.1Content-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).
The text was updated successfully, but these errors were encountered:
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: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:
Response:
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).
The text was updated successfully, but these errors were encountered: