Hi all,
This has come up a few times in recent threads, and I wanted to gather some additional info on your real world use cases. Just reply to me, and any input is appreciated:
1. Does your JSON use snake_case_keys or CamelCase or other?
2. Is the key type consistent throughout the JSON?
3. If JSONEncoder/Decoder converted these, would you have any other need to specify custom keys?
Thanks,
- Tony
this article is a good starting point;
http://benscheirman.com/2017/06/ultimate-guide-to-json-parsing-with-swift-4/
On Jun 23, 2017, at 9:42 AM, Tony Parker via swift-users <swift-users@swift.org> wrote:
Hi all,
This has come up a few times in recent threads, and I wanted to gather some additional info on your real world use cases. Just reply to me, and any input is appreciated:
1. Does your JSON use snake_case_keys or CamelCase or other?
2. Is the key type consistent throughout the JSON?
3. If JSONEncoder/Decoder converted these, would you have any other need to specify custom keys?Thanks,
- Tony_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
1. Does your JSON use snake_case_keys or CamelCase or other?
I usually see snake_case or lowerCamelCase. They are roughly equally common in my experience.
2. Is the key type consistent throughout the JSON?
Usually.
3. If JSONEncoder/Decoder converted these, would you have any other need to specify custom keys?
Often times yes. It is not uncommon to use property names an app that are different than json key names. One example of why this happens is that names used in an app are often aligned with UX terminology which does not always match terminology used by an API. Another reason that is unfortunate but is out of our control is that we are often developing against shifting API specs.
This has come up a few times in recent threads, and I wanted to gather
some additional info on your real world use cases. Just reply to me, and
any input is appreciated:1. Does your JSON use snake_case_keys or CamelCase or other?
It depends on whether API is intended to be used with JavaScript clients.
JavaScript convention is camelBack so for APIs designed with primary
intent of having JavaScript clients it is common to have JSON keys using
the same.
In other cases however snake_case is preferable as it is somewhat easier to
read.
2. Is the key type consistent throughout the JSON?
Hopefully. Inconsistent APIs are painful.
3. If JSONEncoder/Decoder converted these, would you have any other need
to specify custom keys?
Generally yes.
Best regards,
Rimantas
1. Does your JSON use snake_case_keys or CamelCase or other?
My internal APIs use snake_case. Several APIs I write against (not necessarily in Swift), like Heroku and Stripe, also use snake_case. The JSON Feed format uses snake_case.
I suspect the deciding factor is typically the source language—if your backend is written in Perl, Python, or Ruby, you're probably using snake_case. If it's in JavaScript, Java, C#, or Swift, you're probably using camelCase.
2. Is the key type consistent throughout the JSON?
Yes.
3. If JSONEncoder/Decoder converted these, would you have any other need to specify custom keys?
Occasionally, but far less often. For instance, when adapting an API that used Rails conventions, I would still want to translate `created_at` dates to `creationDate`. But that assumes I wanted to use those dates at all—I often ignore them.
If you're considering adding a key transformation strategy to JSONEncoder/Decoder, I strongly encourage you to do so. Case transformation will handle at least 80% of the custom keys, and even when people *do* still need to customize further, case transformation will help them do it more easily. And if you *did* want to provide a `custom` option, it might allow developers to move *all* of their custom JSON key names out of their `Codable` implementations, which would make them easier to use with multiple coders.
On Jun 23, 2017, at 9:42 AM, Tony Parker via swift-users <swift-users@swift.org> wrote:
--
Brent Royal-Gordon
Architechies
Hi all,
This has come up a few times in recent threads, and I wanted to gather some additional info on your real world use cases. Just reply to me, and any input is appreciated:
1. Does your JSON use snake_case_keys or CamelCase or other?
Mostly CamelCase but sometimes Capitalised Spaced Out Keys
2. Is the key type consistent throughout the JSON?
Depends on usage
3. If JSONEncoder/Decoder converted these, would you have any other need to specify custom keys?
Unsure, probably.
On 23 Jun 2017, at 18:42, Tony Parker via swift-users <swift-users@swift.org> wrote:
Thanks,
- Tony_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Hi all,
This has come up a few times in recent threads, and I wanted to gather some additional info on your real world use cases. Just reply to me, and any input is appreciated:
1. Does your JSON use snake_case_keys or CamelCase or other?
My experience is almost always lowerCamelCase. Thinking on that now, I wonder why that is.
3. If JSONEncoder/Decoder converted these, would you have any other need to specify custom keys?
Highly likely. The APIs I've used were developed by different teams and generally had data-like names that do not map well into UI properties.
On Jun 23, 2017, at 12:42 PM, Tony Parker via swift-users <swift-users@swift.org> wrote:
Changes depending on the project. Most seem to be snake case, but the project I'm working on at the moment is lower camel case.
Typically for each API payload yes, but thats not to say there are some bad payload structures out there that mix and match.
It's very common to want to parse a payload key into something different to make more sense when writing against the model in Swift. A simple example are Bool values, a payload might specify a key of available, but you would want to map that to a model property of isAvailable. A simple example but something that comes up a lot.