/v1/auth/{jwt auth path}/roles return 404 if there is no role for a valid JWT auth backend

[viralpoetry]

Describe the bug
For a valid JWT auth backend configured, listing existing roles via API results in HTTP 404 error code if there are no roles defined. I would expect HTTP 200 with an empty list.
Contrary, using Vault CLI, informative answer is returned:

$ vault list auth/jwt/roles
No value found at auth/jwt/roles/

To Reproduce
Steps to reproduce the behavior:

1. Run vault auth enable -path=jwt jwt
2. Setup some indentity provider (not sure if necessary for a reproduction..)

vault write auth/jwt/config \
    jwks_url="https://gitlab.com/-/jwks" \
    bound_issuer="gitlab.com"

3. Run curl --head --header "X-Vault-Token: " --request LIST http://127.0.0.1:8200/v1/auth/jwt/role/
   See the result:

HTTP/1.1 404 Not Found
Cache-Control: no-store
Content-Type: application/json
Date: Thu, 04 Nov 2021 12:24:20 GMT
Content-Length: 59

Response content is {"errors":[]}

Expected behavior
I would expect HTTP 200 with an empty list of roles as I have necessary rights to perform this action.

Environment:

• Vault Server Version (retrieve with vault status): 1.7.2
• Vault CLI Version (retrieve with vault version): 1.7.2
• Server Operating System/Architecture: Ubuntu Linux

Vault server configuration file(s):
for example vault server -dev

[hsimon-hashicorp]

Hi @viralpoetry! This is part of a larger discussion that the engineering team is discussing with regards to evaluating and, as needed, standardizing our HTTP response codes. I'll bring this up with the leadership team to raise awareness. Thanks!

[maxb]

It's not specific to the JWT auth method either, all Vault API collections behave this way.

I think it's unconventional and unhelpful too, and users would be better served (and less surprised) by a 200 OK response containing an empty list - which is what almost any other REST-styled API does in this circumstance.