[#32769] - [4.0][webservice][com_installer] add filtering of data
- Closed
- 9 May 2021
- Medium
- Build: 4.0-dev
- # 32769
- Diff
- alikon:patch-81
User tests: Successful: Unsuccessful:
Summary of Changes
add filtering of data
Testing Instructions
- GET {{base_path}}/api/index.php/v1/installer/manage?core=true/false
- GET {{base_path}}/api/index.php/v1/installer/manage?status=0/1
- GET {{base_path}}/api/index.php/v1/installer/manage?type=component/plugin/module/template
Actual result BEFORE applying this Pull Request
N/A
Expected result AFTER applying this Pull Request
{
"links": {
"self": "https://demo4.loc/api/index.php/v1/installer/manage?core=0"
},
"data": [
{
"type": "manage",
"id": "224",
"attributes": {
"name": "Action Log - Akeeba Backup",
"type": "plugin",
"folder": "actionlog",
"client_id": "0",
"status": "0",
"version": "8.0.1",
"id": "224"
}
},
{
"type": "manage",
"id": "220",
"attributes": {
"name": "Akeeba Backup",
"type": "component",
"folder": "",
"client_id": "1",
"status": "1",
"version": "8.0.1",
"id": "220"
}
},
{
"type": "manage",
"id": "225",
"attributes": {
"name": "Akeeba Backup package",
"type": "package",
"folder": "",
"client_id": "0",
"status": "1",
"version": "8.0.1",
"id": "225"
}
},
{
"type": "manage",
"id": "221",
"attributes": {
"name": "Console - Akeeba Backup",
"type": "plugin",
"folder": "console",
"client_id": "0",
"status": "1",
"version": "8.0.1",
"id": "221"
}
},
{
"type": "manage",
"id": "226",
"attributes": {
"name": "file_fef",
"type": "file",
"folder": "",
"client_id": "0",
"status": "1",
"version": "2.0.1",
"id": "226"
}
},
{
"type": "manage",
"id": "219",
"attributes": {
"name": "file_fof40",
"type": "file",
"folder": "",
"client_id": "0",
"status": "1",
"version": "4.0.2",
"id": "219"
}
},
{
"type": "manage",
"id": "218",
"attributes": {
"name": "Joomla! Patch Tester",
"type": "component",
"folder": "",
"client_id": "1",
"status": "1",
"version": "4.0.1",
"id": "218"
}
},
{
"type": "manage",
"id": "222",
"attributes": {
"name": "Quick Icon - Akeeba Backup Notification",
"type": "plugin",
"folder": "quickicon",
"client_id": "0",
"status": "1",
"version": "8.0.1",
"id": "222"
}
},
{
"type": "manage",
"id": "217",
"attributes": {
"name": "Sample Data - Testing",
"type": "plugin",
"folder": "sampledata",
"client_id": "0",
"status": "0",
"version": "4.0.0",
"id": "217"
}
},
{
"type": "manage",
"id": "223",
"attributes": {
"name": "System - Backup on update",
"type": "plugin",
"folder": "system",
"client_id": "0",
"status": "0",
"version": "8.0.1",
"id": "223"
}
}
],
"meta": {
"total-pages": 1
}
}Documentation Changes Required
| Status | New | ⇒ | Pending |
| Labels |
Added:
?
|
||
when core is omitted it works like before ie all items are returned
core=0 returns entries. Should it?
no
better a 400
{
"errors": [
{
"title": "Invalid field: core",
"code": 400
}
]
}
It is not a consistent to show an error vs. the following.
In this example, a 2 is added at the end.
{
"links": {
"self": "http://localhost/joomla-cms-4.0-dev/api/index.php/v1/installer/manage?type=component2"
},
"data": [],
"meta": {
"total-pages": 0
}
}
these are different things
it has been requested to manage core like boolean hence the check (invalid field)
but for type it's a string so 0 found it's a correct response
I think that the GET verb is wrong in the REST API controller Installer.
/installer is not a data entity. It is a controller/helper itself that provides the behaviour, actions.
It looks odd calling an action with a GET. /installer/manage is a method, so for clarity, it is better if it is called with a POST (even if it doesn't persist a change).
So, if everything that Installer does is managing, then the method manage must return different types of data based on a control parameter. If we follow the Joomla practice, it should have a task parameter to return data or persist changes.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/32769.
beyond the scope of this pr
Thinking twice about the API for extensions, it is not right to publish the "Installer" /installer. It is not the right semantic.
Check the documentation https://docs.joomla.org/J4.x:Joomla_Core_APIs. The entry points are always entities.
It is better to manage the extensions as /api/index.php/v1/extensions/...
For instance, to install an extension you should do a POST /api/index.php/v1/extensions/install.
@anibalsanchez i agree with you - however Nicola is also correct that his pr is just adding filters to an existing endpoint - so can you create a separate issue to track your comment - and I'll try and work on it
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-05-09 07:37:29 |
| Closed_By | ⇒ | alikon |
For
core, should all entries be displayed if true/false is not entered?