feat: warn in development mode when query is missing paging or explicit fields #788
Conversation
There was a problem hiding this comment.
In the current state of the webapi, we can’t assume the presence of full PATCH support, and we cannot rely on PUT requests with mergeMode=MERGE to correctly do partial updates. As such the recommended approach for "partial updates" is:
- GET all owned fields
- Allow editing a subset of these fields
- Update via a
PUTwith defaultmergeMode, which isREPLACE, and make sure the owned fields that were not updated are also included in the request payload.
As such, I think we should NOT show this warning for the :owner field filter right now.
I hope the webapi get full PATCH support at some point and we can start showing warning for :owner as well.
|
I think we should restrict the scope of this change to the resources which we know for sure support paging - that's at minimum 77 of the 88 metadata resources listed at This will avoid noise for resources which don't support paging at all, and these are likely the same resources which support fields parameters - I haven't written a script to test this yet. |
# [2.8.0](v2.7.1...v2.8.0) (2021-03-10) ### Features * warn in development mode when query is missing paging or explicit fields ([#788](#788)) ([5f28c79](5f28c79))
|
🎉 This PR is included in version 2.8.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Eventually we may want to forbid unpaged and ambiguous (no fields specified or dynamic
*/:ownerused) in the runtime. That is likely going to take some time to enforce outright, so this change simply deprecates those features and shows a warning in development mode (hidden in production). This should help us identify and weed out problematic queries in our apps and libraries.Due to the nature of our API we might not be able to enforce this across all endpoints (many endpoints don't have fields or paging as an option at all). As such, this might initially have quite a few "false positives", but we can use those cases to identify and "exempt" the non-normative endpoints from this validation here. The field and paging requirements apply mostly to metadata resources which follow a more traditional REST pattern.