Description
WordPress.org REST API returns an invalid JSON if the resulting response won't contain any data. For example, /wp/v2/users/<user_id>)/application-passwords endpoint only returns the password field while creating a new application token. So, if we make a request and only ask for password field for a GET request, it would return an empty response. The problem is, it returns [[]] instead of [{}] changing the JSON format.
curl --user [email protected]:{token} "http://localhost/wp-json/wp/v2/users/1/application-passwords?context=edit&_fields=password"
We tried to address this problem in #172 by trying to eliminate invalid requests. However, this request ^ is a valid one as far as we are concerned - unless we want to specifically disallow it as a special case - so, our work in #172 does not address this case. (rightly so)
This request currently results in WpApiError::ParsingError which is a decent and hands off way to handle the issue. However, this behaviour seems to be common across all endpoints, so it might be worth to convert this to return either a successful empty response or a specific error.
I am not sold on any solution yet - and maybe what we have right now is the best one after all - so, my main goal with this issue is to document the behavior.
Note that, as I was documenting the issue, I was initially against converting it to a successful response. I thought the response we get back was always [[]] regardless of the number of items, however I've tested this by adding a new application token and observed that the response changed to [[],[]]. So, it looks like the only problem is the conversion from JSON object to JSON array. As long as we are careful with preserving the number of items, I think converting it to a successful response should be fine - although I'd still question its merit. Mainly because when we make a request with _fields=, meaning asking for no fields and treating the request as if we are trying to do a COUNT request, the server responds with all fields. So, I think it'd be kind of against the current API design to do this 🤷
Reminder
In our integration tests, this special case is handled by skipping application-passwords tests that would only request the password field as can be seen in #181. We need to update that implementation as part of this issue.