Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Mike Ralphson
    @MikeRalphson
    @IvanGoncharov excellent. I had spotted json-struct and had a look at the 'differences' doc, but did not fully understand the impetus behind the project, nor realise it was linked to OpenAPI-lint. A recent commit message should have given me the hint!
    Maybe the best way for me to learn about json-struct is to try and raise a PR for this issue (or a subset of it)?
    Ivan Goncharov
    @IvanGoncharov
    PR to json-struct repo?
    if you speak about json-struct document to validate OpenAPI specs
    it's already handled there
    see this trace
    so maxLength defined only if type equal string and validator use this case
    Ivan Goncharov
    @IvanGoncharov
    switch{foo} will extend current object based on value of property foo
    =<JSON value> === { "enum": [ <JSON value> ] }
    ="integer" === { "enum": [ "integer"] }
    think of switch as oneOf where "condition" separated from schema that applied if "condition" matched
    Ivan Goncharov
    @IvanGoncharov
    we wanted to introduce something simular to OpenAPI scheme object instead of discriminator OAI/OpenAPI-Specification#707
    but it after giving it a though it looks like this:
    or this
    Mike Ralphson
    @MikeRalphson
    😆
    Ivan Goncharov
    @IvanGoncharov
    plan to make a talk at RestFest so preparing finny slides
    Sergey Tihon
    @sergey-tihon
    @IvanGoncharov hi, could you please check https://netflix.github.io/genie/docs/rest/swagger.json schema? I got 404 on it
    @IvanGoncharov Out, sorry this one is not from APIs.guru
    Chang-Hung Liang
    @eliangcs
    @IvanGoncharov I was going to build an API directory for HTTP Prompt, but I found you guys. Nice work! I think we can use APIs.guru for API discovery on HTTP Prompt.
    Vikram Rangnekar
    @dosco
    @IvanGoncharov whats the best way to report (or fix) spec issues. I found one in the gmail spec where required id fields are not marked "required: true"
    Ivan Goncharov
    @IvanGoncharov
    @eliangcs Sorry for delay. Need to check chat more frequently
    Yes it would be great if you use data from catalog. It was my original intention to collect these descriptions to allow other developers to build something on creative on top of it
    when you will have public release I can add your project to this list: https://github.com/APIs-guru/openapi-directory#existing-integrations
    Just ping me or send PR
    Ivan Goncharov
    @IvanGoncharov
    @dosco I use official google spec in Discovery format https://www.googleapis.com/discovery/v1/apis/gmail/v1/rest
    So it's better to report this issue directly to Google
    Mike Ralphson
    @MikeRalphson
    This is a request for comments from anyone who is using the current x-origin vendor extension from the APIs.guru catalogue. There is a proposal here APIs-guru/openapi-directory#113 to convert this vendor extension to an array of the current structure. Please give your feedback on the GitHub issue. If no problems are found, it is proposed to make this change from early April 2017.
    Mike Ralphson
    @MikeRalphson
    Just a note that the change of the x-origin vendor extension to an array will be pushed later today unless there are any objections.
    Ignacio Baca Moreno-Torres
    @ibaca
    :+1:
    Mike Ralphson
    @MikeRalphson

    See issue #188 Travis have a new v3 API with a machine-readable definition in their own custom format.

    Would anyone like to have a go at writing a converter for this format to OpenAPI / Swagger v2.0, or be willing to sponsor the effort?

    Mike Ralphson
    @MikeRalphson
    We've just had our first OpenAPI 3.0 definition submitted to the directory, so I guess it's time to start thinking about how to handle this. A lot of tools (e.g. swagger-codegen) still don't support OpenAPI3 (although ReDoc is coming!) so I don't think it's sensible to just convert the whole of the directory en-masse and remove the 2.0 definitions. One option would be to just add OpenAPI3 definitions when they are submitted, as openapi.yaml instead of swagger.yaml. Another option is to add conversions of all the 2.0 definitions - this could be done either in the master branch or in a dedicated openapi3 branch. Please let me know your thoughts...
    Robert Brennan
    @rbren
    I agree, definitely keep the 2.0 definitions for the foreseeable future - many of us depend on them :) I think converting to 3.0 and serving those specs separately would be a good way to go
    Are we able to down-convert new 3.0 definitions to 2.0? It would be a bit annoying to have specs available only in 3.0, but it's better than not having it
    Mike Ralphson
    @MikeRalphson
    Understood. Converting 2.0 to 3.0 is nearly lossless (but not trivial), but I don't know of any 3.0 to 2.0 downconverters. I imagine as more people migrate to 3.0 they will be doing so because they want to use features which aren't supported by 2.0. Still, if someone was to sponsor the work, I'd have a go.... :smile:
    Mike Ralphson
    @MikeRalphson
    As pointed out by @darosh Microsoft have completely re-organised their Azure API collection. This means there is a very large update coming, where serviceNames for existing APIs will change. Please let me know if this is a problem for any integration you have. I propose to defer this update by one week, and implement it from 2017-12-11, but you can preview the changes now in the 'azure' branch.
    Robert Brennan
    @rbren
    @MikeRalphson is there a list anywhere of the Azure name changes? Or a way to get that info?
    Mike Ralphson
    @MikeRalphson
    The source of truth would be the renames in the source Azure repo. There have been at least two. I could look at generating a cross reference. What format would you need?
    Robert Brennan
    @rbren
    anything I could ingest in JavaScript that would map from new_name -> old_name would be super helpful
    Mike Ralphson
    @MikeRalphson
    I'll see what I can do.