Bug 1173096
| Summary: | Support for Filtering child resources | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Operations Network | Reporter: | Libor Zoubek <lzoubek> |
| Component: | REST | Assignee: | Libor Zoubek <lzoubek> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | JON 3.3.0 | CC: | fbrychta, jkandasa, loleary, lzoubek, spinder, theute, vnguyen |
| Target Milestone: | ER01 | Keywords: | Triaged |
| Target Release: | JON 3.3.3 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-07-30 16:41:21 UTC | Type: | Enhancement |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
in master b3de3e99b29ef1fa3a1dceb6551f5a6a470145a0 e1e7bc3cf9ae963711e44b23b9f51f06a7eafb36 As this is already supported via the Java API and it does not make sense that our APIs implement a completely separate set of functions, one could argue that this is a bug. Furthermore, the fact that you have to retrieve all the child resources means that the client application would most likely require a very large amount of memory and therefore the result of using the resource/{id}/children endpoint could result in memory errors without a way for the user to get around them.
This fix should be considered for the 3.3 stream to improve user-experience and make the REST API more usable and aligned with the Java API.
Setting target to 3.3.3 for consideration in next maintenance release.
Available for test with 3.3.3 ER01 build: https://brewweb.devel.redhat.com/buildinfo?buildID=446732 *Note: jon-server-patch-3.3.0.GA.zip maps to ER01 build of jon-server-3.3.0.GA-update-03.zip. Executed the following queries and works as expected, http://<hostname:port>/rest/resource/search?parentId=10003&ps=100 http://<hostname:port>/rest/resource/search?parentId=10003&ps=100&availability=DOWN http://<hostname:port>/rest/resource/search?parentId=10003&ps=100&availability=UP http://<hostname:port>/rest/resource/search?plugin=JBossAS7&ps=100&availability=UP http://<hostname:port>/rest/resource/search?plugin=JBossAS7&ps=100&availability=UP http://<hostname:port>/rest/resource/search?status=COMMITTED http://<hostname:port>/rest/resource/search?status=NEW http://<hostname:port>/rest/resource/search?status=COMMITTED&category=Platform http://<hostname:port>/rest/resource/search?status=COMMITTED&category=Server&parentName=rhq http://<hostname:port>/rest/resource/search?status=COMMITTED&category=Server&parentName=rhq&type=Cassandra Server JVM http://<hostname:port>/rest/resource/search?type=Cassandra Server JVM http://<hostname:port>/rest/resource/search?type=File System Build Information: Version : 3.3.0.GA Update 03 Build Number : e4b348a:2f80c8c Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-1525.html |
Description of problem: Our REST API is not capable of filtering child resources by category or any other criteria. The only way clients have is to get all child resources from API and filter results in memory. Version-Release number of selected component (if applicable): JON 3.3.0.GA How reproducible: always I think we should at least implement an easy filter for GET /resource/{id}/children that could accept the same @QueryParams as /resource but I'd like to introduce something more powerful. Let's say GET /resource/search where query parameter i.e "parentResourceId=2" would be mapped to ResourceCriteria#addFilterParentResourceId(2) This search endpoint would be generic enough to support all filter options we have + we can introduce some special queryParams like strict=false|true. GET /resource/search would be a better (more general) replacement for GET /resource/{id}/children