Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Ivan Goncharov
    @IvanGoncharov
    So is it critical to support previous version?
    Mohsen Azimi
    @mohsen1
    you can write your API without thinking about backward compatibility
    Ivan Goncharov
    @IvanGoncharov
    cool. Thanks
    one thing trough
    Mohsen Azimi
    @mohsen1
    then we can shell it with a wrapper that allows both APIs
    I can do that work
    Ivan Goncharov
    @IvanGoncharov
    it can't be done
    you can't convert from array to object with uniq keys
    Mohsen Azimi
    @mohsen1
    Can you give me a usage example of the new API?
    Maybe I don't understand it right
    Ivan Goncharov
    @IvanGoncharov
    I will explain using test that I made
    it will be these lines
      {
        resourceListing: 'fixable/index.json',
        apiDeclarations: {
          '/pets': 'fixable/pets.json',
          '/stores': 'fixable/stores.json'
        },
        output: 'fixable.json'
      }
    see how apiDeclarations became object
    Mohsen Azimi
    @mohsen1
    so if I provide an array, you should be able to abstract the basePath from contents of each JSON file. Isn't that what we're doing at the moment?
    Ivan Goncharov
    @IvanGoncharov
    in this interface you clearly see relationship between main resource and declarations
    basePath in resources is making calls
    on the other hand descriptions inside resource tied to path
    which is path to resource itself
    in many cases they have similar ending
    that is heuristic that is used right now
    I solve this by using path from resourceListing as key for resource itself
    Mohsen Azimi
    @mohsen1
    Hmm... so per specs there is no guarantee that you get right basePath from JSON content. Right?
    Ivan Goncharov
    @IvanGoncharov
    you can get basePath for calling APIs
    but if you want to find out path to resource from resource content
    it because tricky
    in theory it should be solved by resourcePath
    problem is that it optional field
    Mohsen Azimi
    @mohsen1
    oh if it's optional we can't rely on that
    Ivan Goncharov
    @IvanGoncharov
    and even if it present
    in many cases it have incorrect values
    actually in most of the cases
    Mohsen Azimi
    @mohsen1
    I see.
    Ivan Goncharov
    @IvanGoncharov
    so what I'm trying to do
    Mohsen Azimi
    @mohsen1
    Ok, I'm convinced this API change is a good move
    but it should be done very carefully
    A lot of people are using this tool https://www.npmjs.com/package/swagger-converter
    first of all it should be part of a major release
    Ivan Goncharov
    @IvanGoncharov
    That is why I want to do this in 1.0.0
    Mohsen Azimi
    @mohsen1
    We should also throw proper errors if people are passing arguments based on previous API syntax
    Ivan Goncharov
    @IvanGoncharov
    Ok
    Mohsen Azimi
    @mohsen1
    Awesome!
    Ivan Goncharov
    @IvanGoncharov
    and if you want to use it in swagger-converter
    CLI syntax should be changed
    Mohsen Azimi
    @mohsen1
    in swagger-tools you meant, right?
    ok, those are steps after we release 1.0
    Ivan Goncharov
    @IvanGoncharov
    yes, swagger-tools
    Mohsen Azimi
    @mohsen1
    swagger-tools is kind of being replaced by sway and swagger command line tool (npm i -g swagger)