-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add search exposed config endpoint #240
base: main
Are you sure you want to change the base?
Conversation
@abollini : Adding you as a reviewer of this REST Contract update, since you had recommended this approach in a Dev Mtg. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @J4bbi for this. I've just left you two comments, please feel free to consider them. To me, this PR should be still considered in this Release.
configuration.md
Outdated
|
||
## Search methods | ||
### top |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why the Top here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the top
configuration.md
Outdated
## Search methods | ||
### top | ||
**/api/config/properties/search/exposed** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've seen this in other endpoints, to be consistent it could be - isExposed, like:
/api/config/properties/search/isExposed
I let to you to decide, both approaches are ok with me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to isExposed
as suggested
94f9b1b
to
f47335d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @J4bbi thanks for this contribution, it opens the door to performance improvement on the angular side to deal with backend managed configuration. I have provided some feedback inline
|
||
* 200 OK - if the operation succeeded | ||
* 404 Not found - if no property is configured to be exposed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be an empty list but still 200.
The endpoint must support pagination parameters according to our general rules https://github.com/DSpace/RestContract?tab=readme-ov-file#pagination
|
||
```json | ||
[{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to follow the usual HAL format for resource collections having an embedded with the pagination information
|
||
## Search methods | ||
**/api/config/properties/search/isExposed** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not completely sure about the path isExposed
but I'm not against it. Just adding this comment to share my thought. It was looking strange to me at a first look but I haven't found any direction in our naming convention https://github.com/DSpace/RestContract?tab=readme-ov-file#on-the-naming-of-endpoints
I found that we have a lot of diversity in the way that search methods have been named so far
- some start with findBy...
- other start with byXXX
- allmost all seems to use the CamelCase convention (that we decide to avoid for the resource collection endpoints)
Fixes DSpace/DSpace#9056 as discussed in DevMtgs 14th and 21st September 2023.
This PR adds an endpoint to the configuration endpoint to more efficiently share configuration with the frontend.
Current approach
Add the /api/config/properties/search/exposed endpoint, as per the top communities search endpoint.
Pros
API endpoint url is clear.
Cons
Endpoint url is not consistent with the single case, /api/config/properties/<:property>.
Alternative approach
I am a little undecided about whether I feel /api/config/properties would be a better solution and just implementing the missing findAll method.
Pros
There is consistency in the naming of the endpoints. /api/config/properties/<:property> for a single configuration and /api/config/properties/ for every single one.
Cons
It might not be apparent that this endpoint is limited to whitelisted, exposed configuration.