Thanks for the info -- makes sense. Note that Swagger does have a dynamic JS library in addition to swagger-codegen (https://github.com/swagger-api/swagger-js), though I've not used it so I don't know what its strengths/weaknesses are.
On Thursday, November 17, 2016 at 1:44:28 AM UTC-8, Tom Christie wrote: > > Hi Paul, > > The Swagger codegen approach and the Core API dynamic client library > approach are a little different. > In the former you're required to generate a new client library for every > API (or API version) you want to interact with. > In the later there's a single client library that's dynamic, so exactly > the same library can be used with many different > APIs and API versions. > > > Is this specifically for CoreAPI=>JS > > No. Core API is about specifying how we can represent network interfaces > in a format independent manner. That means we can support any schema that > there's a codec for. (a mapping from the encoded representation to a Core > API data model). Yes, we would need to implement codecs for each of > Swagger, RAML, API Blueprint etc. but that's *significantly* less work than > building tooling out for each of them independently. > > > are the CoreAPI JS clients going to be better than the SwaggerJS clients > in some way? > > They'll be different. A dynamic client library, rather than codegen. > There's clearly some advantages to the dynamic approach, yes, but they're > both valid. > > Hope that helps? > > Tom > -- You received this message because you are subscribed to the Google Groups "Django REST framework" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
