drop 1.0, 1.1, 1.2 code, build a 2.0 transformer

[fehguy]

The swagger-compat library keeps the code separate, but we should really remove it all, and add a simple converter from the 1.x specs to 2.0. Then the same 2.0 codepath can be used.

[mohsen1]

We build a convertor from 1.2 to 2.0 here
https://github.com/apigee-127/swagger-converter

[whitlockjc]

In all honesty, 1.2 and 2.0 aren't all that different. In swagger-tools, we have one code base that works with both types without a lot of effort. It's not perfect but it felt a lot better than separating implementations only to have a bunch of copy/paste/duplication. What if we were to have a version-specific object model but a single source base that handled both intelligently? Just a thought.

[fehguy]

There are similarities when done right, once you fetch the apiDeclaration files. My thought was that the transformer would be rein single for fetching the additional files (with authentication as needed) by using the same underlying swaggerHttp object. We then have different transformers for each spec version. Make sense?

[whitlockjc]

I don't know the API well enough yet to answer but when I do, I'll let you know.

[fehguy]

My view on the API to invoke the transformer is something along these lines:

var spec = ....;
var version = parseFloat(spec.version);
if(version === 1.2) {
  new Swagger12Transformer().resolve(spec, // spec passed in by swagger-ui
    self.buildFromSpec, // callback to build the client from a 2.0 spec
    self);              // scope for the callback
}
else if(version === 1.1) {
  // ...
}

[fehguy]

this would allow us to remove the entire swagger-compat.js class.

[fehguy]

see here: #309

Remaining tasks:

• migrate api descriptions to tags
• add security definitions
• handle .{format} on execute