Invalid field specified errors while trying to use custom vars in v/objects/hosts API

Describe the bug

While requesting host objects to Icinga2 API using the v1/objects/hosts endpoint , it is not possible to limit returned attributes to a specific custom variable.

Here the call that produces the error:

curl -k -X GET -u '<USERNAME>:<PASSWORD>' 'https://127.0.0.1:5665/v1/objects/hosts?pretty=1&attrs=vars.host_os'
{
    "error": 400,
    "status": "Invalid field specified: vars.host_os"
}

If I just restrict output to the whole vars dictionary ( attrs=vars ), the API call works fine, but the output contains all the custom variables, and this is not what I want.

Expected behavior

Other APIs can successfully address a single custom variable (see as example https://icinga.com/docs/icinga-2/latest/doc/12-icinga2-api/#creating-config-objects), so I am expecting to be able to select which custom variables include in the output.

If this is the intended behavior, documentation is not clear about it.

Your Environment

Include as many relevant details about the environment you experienced the problem in

# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: r2.14.2-1)

Copyright (c) 2012-2024 Icinga GmbH (https://icinga.com/)
License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl2.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

System information:
  Platform: Red Hat Enterprise Linux
  Platform version: 8.10 (Ootpa)
  Kernel: Linux
  Kernel version: 4.18.0-553.22.1.el8_10.x86_64
  Architecture: x86_64

Build information:
  Compiler: GNU 8.5.0
  Build host: staging7681master
  OpenSSL version: OpenSSL 1.1.1k  FIPS 25 Mar 2021

• Enabled features (icinga2 feature list): api checker ido-mysql mainlog notification

Reproduce the request against the v1/objects/hosts endpoint with attrs=vars.host_os and compare it with attrs=vars. Then inspect the API behavior documented under “Creating config objects” and determine whether selecting a nested custom variable should work; done means the request behaves as expected or the limitation is clearly documented.