Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why does collection response use value property instead of values in Azure API guidelines? #539

Open
zendu opened this issue Apr 15, 2024 · 2 comments

Comments

@zendu
Copy link

zendu commented Apr 15, 2024

I am looking at Azure API guidelines - Collections section. https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md#collections

YOU SHOULD use value as the name of the top-level array field unless a more appropriate name is available.

I am curious to know why a property is using singular word when it represents a collection of entities.

@JeffreyRichter
Copy link
Contributor

You have a good point. An array could certainly be thought of as a single value that happens to be an array. And https://www.json.org/json-en.html on the right has a pane that shows "value" with "array" under it. So, to JSON an array is a value (not values).

But honestly, when the Azure API Stewardship board took over these REST guidelines, we looked at existing Azure services and they were using "value" and so we just kept it to reduce inconsistencies.

If we were re-designing everything from scratch, I'm not sure if we'd keep value or switch to values but, fortunately, we don't have to have this debate within our team.

@Ernest3688
Copy link

The Azure API guidelines often use the value property instead of values in collection responses for consistency and clarity. This is a design choice made to maintain uniformity across various Azure APIs, making it easier for developers to understand and work with different services within the Azure ecosystem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants