Always return an object from API methods and deprecate all existing API methods#1054
Always return an object from API methods and deprecate all existing API methods#105412 commits merged into
Conversation
|
I do think that the new names are better than the old ones, but is it worth the change to get better names? #790 suggests that it should be possible to send deprecation messages with the result message, and that can sound appealing but would that really work? Who would read those messages? Do you envision that those messages are shown to the Zonemaster GUI users? Or how should those messages go to some maintainer? |
Do we think this is a change we'd like to see at some point? Do we want to harmonize the API? Do we want to clean our codebase? I would answer yes to all. |
|
|
|
Good point, I like |
|
E.g. method Else this looks good. |
|
I planned to do this on a second stage, ie in a follow-up PR. If this is ok, could you approve this PR? |
That is also fine. |
| connect "system_version" => { | ||
| handler => $handler, | ||
| action => "system_version" |
There was a problem hiding this comment.
"system_version" -> "system_versions"
(two occurrences)
| * [API method: conf_profiles](#api-method-conf_profiles) | ||
| * [API method: conf_languages](#api-method-conf_languages) | ||
| * [API method: lookup_address_records](#api-method-lookup_address_records) | ||
| * [API method: lookup_delegatio_data](#api-method-lookup_delegation_data) |
There was a problem hiding this comment.
lookup_delegatio_data -> lookup_delegation_data
| }; | ||
| }; | ||
|
|
||
| if ($config->RPCAPI_enable_add_api_user) { |
There was a problem hiding this comment.
Shouldn't this PR also introduce the new appropriate, unused config parameter RPCAPI_enable_user_create ?
There was a problem hiding this comment.
good point, I've created this new config parameter and marked old one as deprecated
| }); | ||
| } | ||
|
|
||
| if ($config->RPCAPI_enable_add_batch_job) { |
There was a problem hiding this comment.
Shouldn't this PR also introduce the new appropriate, unused config parameter RPCAPI_enable_batch_create ?
There was a problem hiding this comment.
good point, I've created this new config parameter and marked old one as deprecated
And mark old ones as deprecated
Some old API methods were already returning an object. This object can be returned.
* Document new API methods * Mark old API methods as deprecated * Link to new API methods from deprecated one * Update return values for new API methods
* create "RPCAPI.enable_batch_create" and "RPCAPI.enable_user_create" * mark "RPCAPI.enable_add_batch_job" and "RPCAPI.enable_add_api_user" as deprecated
|
Release test successful. I found one minor latent issue, #1105. But it’s very minor (it’s only visible by manually poking at the API) and seems more like an old oversight. It is not a regression introduced by this pull request, so this issue should not prevent the upcoming release from taking place. |
Purpose
The current API methods return different object types in the "result" property. In #790 it has been discussed the need to always return an object to facilitate expanding the results. It was also noted that the API methods' names could be harmonized and improved. This first work is about providing new API methods based on the discussion in #790, and deprecate all existing API methods.
This is the first step of the process:
Mapping between old and new method names:
version_infosystem_versionsprofile_namesconf_profilesget_language_tagsconf_languagesget_host_by_namelookup_address_recordsget_data_from_parent_zonelookup_delegation_datastart_domain_testjob_createtest_progressjob_statusget_test_resultsjob_resultsget_test_paramsjob_paramsget_test_historydomain_historyadd_api_useruser_createadd_batch_jobbatch_createget_batch_job_resultbatch_statusContext
Partially addresses #790.
Changes
Deprecate all existing API methods, see the array in the Purpose section for the new method names.
How to test this PR
Test should pass. At this stage the new methods are not used.