Use case: I documented an API endpoint with 5 attributes in the response. Developers added 5 more attributes without telling me, one of them being a required one.
My tests are passing for responseData for the 5 old attributes, and I only get to know the issue when someone spots the “required attribute missing” error.
If none of the new attributes are required, I might never get to know the existence of new attributes.
Response:
So today we do inclusive data matching, meaning that as long as at least the specified responseData values are present, the step passes. But you want to do exslusive data matching, meaning that if any fields are present that aren't expected, you want the step to fail.
Analysis:
JSON schema has an additionalProperties boolean that we might be able to mirror the behavior of. This would only be applicable to responseData, not responseHeaders.
hawkeyexl
commented
2 months ago
From Subin:
Use case: I documented an API endpoint with 5 attributes in the response. Developers added 5 more attributes without telling me, one of them being a required one.
My tests are passing for responseData for the 5 old attributes, and I only get to know the issue when someone spots the “required attribute missing” error.
If none of the new attributes are required, I might never get to know the existence of new attributes.
Response:
So today we do inclusive data matching, meaning that as long as at least the specified responseData values are present, the step passes. But you want to do exslusive data matching, meaning that if any fields are present that aren't expected, you want the step to fail.
Analysis:
JSON schema has an
additionalPropertiesboolean that we might be able to mirror the behavior of. This would only be applicable to responseData, not responseHeaders.