[MGNLREST-224] Specify fields to return Created: 10/Feb/20 Updated: 26/Jan/24 Resolved: 22/Jan/24 |
|
| Status: | Closed |
| Project: | Magnolia REST Framework |
| Component/s: | None |
| Affects Version/s: | 2.2.24 |
| Fix Version/s: | 3.0.0, 2.2.25 |
| Type: | Story | Priority: | Neutral |
| Reporter: | Christopher Zimmermann | Assignee: | Oanh Thai Hoang |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 3d 5.5h | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||
| Task DoD: |
[X]*
Doc/release notes changes? Comment present?
[X]*
Downstream builds green?
[X]*
Solution information and context easily available?
[X]*
Tests
[X]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||||||||||
| Release notes required: |
Yes
|
||||||||||||||||||||||||||||||||
| Documentation update required: |
Yes
|
||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||
| Epic Link: | Support | ||||||||||||||||||||||||||||||||
| Team: | |||||||||||||||||||||||||||||||||
| Work Started: | |||||||||||||||||||||||||||||||||
| Approved: |
Yes
|
||||||||||||||||||||||||||||||||
| Description |
|
As a Developer, I can specify which fields I want and which ones I do not want in the response, so that I have an efficient clean response to work with. We want to support configuring this both on the definition, and as querystrings - in order to be very useful and handle developers use cases. An important usecase is that a developer wants to prevent some fields from being returned. So if fields are not returned based on the definition - the querystring should NOT BE ABLE to make thoes fields be returned. Acceptance Criteria:
|
| Comments |
| Comment by Christopher Zimmermann [ 02/Sep/20 ] |
|
While an equivalent feature is available in GraphQL endpoint, this is still very useful in REST endpoint as REST endpoint supports additional features that developers may want to use it in combination with. |
| Comment by Christopher Zimmermann [ 11/Jan/24 ] |
|
Note that the acceptence criteria of being able to configure which fileds are returned from a reference resolver is exactly what is requested here: https://jira.magnolia-cms.com/browse/SUGGEST-288 |
| Comment by Christopher Zimmermann [ 11/Jan/24 ] |
|
And the same is requested here: https://jira.magnolia-cms.com/browse/MGNLREST-328 |
| Comment by Christopher Zimmermann [ 11/Jan/24 ] |
|
For the names of the parameters, I think it is a good idea to find names that relate to our existing relevant naming which is "includeSystemProperties" and "systemProperties". In Magnolia we use the term "properties" usually - not "fields" as some others do. Therefore I recommend we use the names: `properties` - you specify the list of properties to return. (whitelist) `excludeProperties` - you specify list of propeties to not return. (blacklist) — As discussed- it is only supported to have either whitelist or blacklist. If both are present, either throw an error - or disregard the "excludeProperites" configuration. (However its OK for the main definition to use either blacklist or whiltelist - and each referenceResolver could use blacklist or whitelist.) |