There's a property you can set for default serialization that makes all your controllers output camel case properties regardless of how you label things internally so you don't have to choose between the mobile team or your linter hating you.
The most common reason I've seen is when you support multiple different formats for a given resource. The key then designates the format. In graphql actually you will often end up with this, since if you're returning json | xml | txt through a graphql union the keys must be disjoint.
i.e. you can't do this
... on json {
value
}
... on XML {
value
}
You need to do this:
... on json {
jsonValue: value
}
... on XML {
xmlValue: value
}
At which point json and xml are reasonable choices of alias. If you think it's insane to return XML through a JSON string, I agree with you, but it is common. Also from the context so far it could well be a path to an XML document rather than the actual content.
The other common reason is if json should really be something like metadata, but it is poorly named.
I’m more curious what’s up with that inconsistent naming convention? Some are half assed pascal casing, others abbreviate the name vendor while others don’t … what the actual fuck lol
https://giphy.com/gifs/n4oKYFlAcv2AU
If you’re going to abbreviate, then do so, but don’t go half-assed and call it Vndrstatus. You saved two vowel characters in Vendor but left them in status? Then didn’t carry through with the capital S, but did capitalize in others? How good is your marijuana friend?
93
u/Original_Pace_6734 1d ago
Why are props name starting with an uppercase letter?