[Swift3] Decoder might be a little bit more liberal

[rdalverny]

Description

It happens that some server implementations send booleans or integers as strings, yet the client library expects a boolean or an integer (this is somewhat messy, agreed - in my case).

At this point, on such case, a generated Swift3 client will fatalError("Source \(source) is not convertible to type \(clazz): Maybe swagger file is insufficient") (in swift3/Models.mustache#L92).

Well, the server implementations could be more up to spec, although that's not always the case. The client could just accept only strings and later do the conversion.

However, having the client library cast the server response in the correct type at once would be nice (the Java client library does this, as it relies on gson). More, this also allows the server implementations to stay as they are, or to get up to spec, without having to update the client code.

Swagger-codegen version

I am using the HEAD revision at this point.

Steps to reproduce

• in the definition, declare a JSON attribute response for a service to be an integer or a boolean
• have a particular server send a string-encoded integer or boolean ("123" instead of 123, or "true" instead of true)
• generate the client Swift3 library
• query the service
• appreciate the decoder fatally complain about it

Related issues

I am not sure, I'm new to this (Swift and Swagger). However:

• 2735, although closed, seems related; I am not sure the suggested solution (use "object" for arbitrary JSON data) is appropriate when we have simple types that may be trivially converted (client expecting an int, server sending an int encoded as a string);

• 5543 is, the other way around (converting a string into a boolean) - just for context; I don't think it has any significance here;

• 4382 is, in the way an mismatch is handled (fatalError)

• could #3596, #2133 be, for some context on the decoding part?

Suggest a Fix

I am not sure this is the best way to fix this, or even if there would not be a better, more generic way in Swift. However the following comes to work on my side (apart from fixing the server implementations of course). Would using a specialized library be better (hkellaway/Gloss, ikesyo/Himotoki or other - at this point, I really have no idea)?

--- a/modules/swagger-codegen/src/main/resources/swift3/Models.mustache
+++ b/modules/swagger-codegen/src/main/resources/swift3/Models.mustache
@@ -73,11 +73,20 @@ class Decoders {
             return (source as! NSNumber).int32Value as! T;
         }
         if T.self is Int64.Type && source is NSNumber {
-            return source.int64Value as! T;
+            return (source as! NSNumber).int64Value as! T;
+        }
+        if T.self is Int32.Type && source is String {
+            return (source as! NSString).intValue as! T;
+        }
+        if T.self is Int64.Type && source is String {
+            return (source as! NSString).intValue as! T;
         }
         if T.self is UUID.Type && source is String {
             return UUID(uuidString: source as! String) as! T
         }
+        if T.self is Bool.Type && source is String {
+            return (source as! NSString).boolValue as! T;
+        }
         if source is T {
             return source as! T
         }

[ePaul]

I don't like adapting to a server who doesn't follow its own specification. JSON has just 5 types (or 7 if you count null, and integer separately from number) ... and still people succeed to use the wrong ones :frowning_face:.

If at all, that kind of behavior should only be available as a (non-default) option.

[rdalverny]

I agree it's far from beautiful but:

• swagger is not always used as an all-or-nothing solution; server & client implementations may not necessarily be coupled with each other, it happens in legacy environments; it surely may be fixed in other ways upstream, but that may not be the fastest way either;
• that kind of behavior as I see it is more about being liberal in accepting/casting received data, as long as it's safe - it's a convenience. What would be the downsides?

[ePaul]

The problem with Postel's principle (the part "be liberal in what you accept") is that people start to rely on the behavior. If data consumers start to accept strings instead of other values, then data producers will start to send strings where numbers are meant (without anyone noting that they are doing wrong things). And then other consumers break, so those need to be adapted too ... and so on.

This is why I would like to have this feature protected with some option, so it is not in widespread usage, but just used where we know it is needed (like your example).

[rdalverny]

Fully agree. Here's a possibility: https://github.com/rdalverny/swagger-codegen/commit/209c7c50ab506d19cd12f567d8d1dc335dc41a5d. Shall I push it as a PR or do you have any feedback before at this point (I'm not sure I did it all right regarding the option addition)?

[ePaul]

Looks fine from the distance (I don't know Swift enough to be able to judge about that, and didn't load the Java part in the IDE).