[swift-corelibs-dev] Adding type conversion capabilities to JSON encode/decode

[Sneed, Brandon]

Just a quick follow up on that last reply…

As dumpy of an excuse as that is (doing it because the other 2 big platforms do it) when we’re talking about some tech that is very cross platform, I think it’s worth considering.


Brandon Sneed

From: <swift-corelibs-dev-bounces at swift.org> on behalf of "Sneed, Brandon via swift-corelibs-dev" <swift-corelibs-dev at swift.org>
Reply-To: "Sneed, Brandon" <brsneed at ebay.com>
Date: Wednesday, August 30, 2017 at 3:29 PM
To: Tony Parker <anthony.parker at apple.com>
Cc: "swift-corelibs-dev at swift.org" <swift-corelibs-dev at swift.org>
Subject: Re: [swift-corelibs-dev] Adding type conversion capabilities to JSON encode/decode

Yeah, I don’t know about the “many types” part.  But essentially, if you’re a service developer, you’ll probably have at least 3 clients.  Web, Android and iOS.  Javascript does this conversion transparently, GSON also does this conversion.  iOS ends up being the odd man out in this case.

This is entirely me trying to put myself in the service developers shoes… but if I come up with an API contract, that will typically consist of endpoint, overall structure and namin.  I can imagine type may fall off my radar given that javascript (the platform I wrote my service in) hides types from me.  Using that example at a larger company, the “hey you broke me by changing the type!” scream is followed with “it works fine on web and android”, which in turn causes me to rev the iOS app and wait for people to update.

If it failed on all 3, they’d likely fix/rever the service to avoid having *all* clients broken.


Brandon Sneed

From: <anthony.parker at apple.com> on behalf of Tony Parker <anthony.parker at apple.com>
Date: Wednesday, August 30, 2017 at 3:22 PM
To: "Sneed, Brandon" <brsneed at ebay.com>
Cc: Youming Lin <ylin at us.ibm.com>, "swift-corelibs-dev at swift.org" <swift-corelibs-dev at swift.org>
Subject: Re: [swift-corelibs-dev] Adding type conversion capabilities to JSON encode/decode





On Aug 30, 2017, at 3:12 PM, Sneed, Brandon <brsneed at ebay.com<mailto:brsneed at ebay.com>> wrote:

Thanks Tony,

Ah.  That should work, and covers benefit #2 I mentioned very nicely.  Only downside is that as a developer on an app I may not expect that type to change on the server side so I wouldn’t do it by default, and when it does happen, I then need to apply it to each of its siblings because if it can happen to one, it can happen to the others.

In this case, the server decides to send a String instead of a numeric value for many kinds of types?

I understand that some JSON libraries have options to stringify all numeric values in an attempt to preserve ‘exactness’, although I would argue that this depends on what you do with the numeric value on the other side…

- Tony




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20170830/fe256aee/attachment.html>