Allow Data as Serialized object even if is not valid json

[MP0w]

This enable Kakapo to stub other kind of requests, for example we can create a XMLSerialzier that when serialized returns the object as Data, or we can implementer Serialziable for UIImage, a really powerful feature that let us use Kakapo not only for JSON responses but every kind of response.
This is a basic change that enable us to do so, some more documentation might be written in future and we might decide to move in a direction where Kakapo is less JSON centric

Example:

extension UIImage: ResponseFieldsProvider {

    public var statusCode: Int {
        return 200
    }

    public var body: Serializable {
        return UIImagePNGRepresentation(self)
    }

    public var headerFields: [String : String]? {
        return ["Content-Type": "image/png"]
    }
}

Usage:

router.get("image.png") {
   return UIImage(named: "whatever")
}

[houndci-bot]

Line Length Violation: Line should be 100 characters or less: currently 293 characters (line_length)

[houndci-bot]

Line Length Violation: Line should be 100 characters or less: currently 213 characters (line_length)

[joanromano]

@MP0w in your example: how is the result of UIImagePNGRepresentation(self) a valid Serializable object for the body var? Isn't that a NSData return type?

[joanromano]

Also toData() is not a requirement from ResponseFieldsProvider is it?

[MP0w]

Sorry toData is not needed, forget about it.
NSdata is not serializable by itself but Optional is serializable

[joanromano]

I see. Then since the serialization also supports Data now, how about making Data/NSData also CustomSerializable by default? This way we don't need to always wrap Data into an Optional, which maybe is not the best for other scenarios.

I think we really should update README to document this properly before merging, otherwise it's a bit misleading how to use it.

[joanromano]

Also, adding a test which shows this usage together with a Router might be also helpful and self documentary for ourselves in the future.

[joanromano]

Interesting your point regarding being less JSON centric: if we have to support different serializations, we might have to separate into different serialization types and wrap everything into a serialization process that takes all types into account maybe.

[MP0w]

The non-JSON centric thing needs a major revision of documentation, README and the way we advertise Kakapo. That's why I think for the moment we can enable it (which is something I would expect to work) and later tackle it

[MP0w]

"adding a test which shows this usage together with a Router might be also helpful" this is already tested I think, router will accept any Data without caring what it contains, because is the only thing needed to create a response

[joanromano]

Yup, didn't say it was not tested: just that it would be self documentary for us in the future I believe.

[MP0w]

@joanromano I wouldn't make Data Serializable because it should be since it doesn't make sense to have it inside a json but only as a replacement for json... what we have to do is to decouple Kakapo from json and requiring a DataConvertible instead of current Serializable... json wouldn't be anymore a special case, just something that can be converted to data.

[MP0w]

I will work on something and see how it goes