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: <[email protected]> on behalf of "Sneed, Brandon via 
swift-corelibs-dev" <[email protected]>
Reply-To: "Sneed, Brandon" <[email protected]>
Date: Wednesday, August 30, 2017 at 3:29 PM
To: Tony Parker <[email protected]>
Cc: "[email protected]" <[email protected]>
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: <[email protected]> on behalf of Tony Parker 
<[email protected]>
Date: Wednesday, August 30, 2017 at 3:22 PM
To: "Sneed, Brandon" <[email protected]>
Cc: Youming Lin <[email protected]>, "[email protected]" 
<[email protected]>
Subject: Re: [swift-corelibs-dev] Adding type conversion capabilities to JSON 
encode/decode





On Aug 30, 2017, at 3:12 PM, Sneed, Brandon 
<[email protected]<mailto:[email protected]>> 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




_______________________________________________
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Reply via email to