Forum Discussion
SharePoint Search API response schema changes
- My take is this. You should only expect properties you ask for. These may or may not have values depending on the property. As such, you should not have a rigid schema to validate returned data.
DocumentSignature/CollapseStatus are by no means new ones. As for other props these can and will change as we make changes. And the schema contract is a weak one and you should only count on any public documented properties or those you have created yourself.
Hope this makes sense š
Here are some findings in the results I'm getting. I've updated my power automate json schema (now I will always put things like "anyOf": ["type": "string", "type": "null"] in my schema definition) but I'm worried about the impact of these types of changes as I'm building flows for a lot of customers...:
RelevantResults.Properties
Removed
ā GenerationId
ā indexSystem
ā GeoLocationSource
Table.Rows.Cells
Changes
UniqueID:
Before Example: "Value": "36b8e7c3-deb7-42a2-89bf-551ccbbab779"
Now : "Value": "{36b8e7c3-deb7-42a2-89bf-551ccbbab779}"
PartitionId
Before Example: "Value": "a348e418-3879-46f3-b30e-c4bc1eaca908", "ValueType": "Edm.Guid"
Now: "Value": null, "ValueType": "Null"
Culture
Before Example: "Value": "fr-FR","ValueType": "Edm.String"
Now: "Value": null, "ValueType": "Null"
MicrosoftDocumentSignature/CollapseStatus are by no means new ones. As for other props these can and will change as we make changes. And the schema contract is a weak one and you should only count on any public documented properties or those you have created yourself.
Hope this makes sense š