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 maxLength defined only if type equal string and validator use this case
    switch{foo} will extend current object based on value of property foo
    =<JSON value> === { "enum": [ <JSON value> ] }
    ="integer" === { "enum": [ "integer"] }
    Ivan Goncharov
    @IvanGoncharov
    think of switch as oneOf where "condition" separated from schema that applied if "condition" matched
    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:
    Ivan Goncharov
    @IvanGoncharov
    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.
    Robert Brennan
    @rbren
    thanks!
    Robert Brennan
    @rbren
    @MikeRalphson, any update here? If you can point me in the right direction I'm happy to take a crack at it.
    Mike Ralphson
    @MikeRalphson
    @bobby-brennan not yet. I think the approach would be to get a list of renames from the azure sdk repo history, and then compare those to the origin entries (then and now) in the directory repo. I can get you the relevant commit ids...
    Robert Brennan
    @rbren
    sounds good. Looks like a few AWS API names changed as well?
    those I can probably just match up manually
    Mike Ralphson
    @MikeRalphson
    Yes, some filenames changed to ensure they reflected the serviceName property rather than the source AWS filename.
    Sergey Tihon
    @sergey-tihon

    I found schemas like https://api.apis.guru/v2/specs/azure.com/automation-softwareUpdateConfiguration/2017-05-15-preview/swagger.json that contains reference to definition in relative document "$ref":"./definitions.json#/definitions/softwareUpdateConfigurationCollectionItem” but I cannot find definitions.json near the schema file https://github.com/APIs-guru/openapi-directory/tree/master/APIs/azure.com/automation-softwareUpdateConfiguration/2017-05-15-preview

    I there any way to resolve such references? // cc @IvanGoncharov

    Mike Ralphson
    @MikeRalphson
    @sergey-tihon yes, sway, the resolution and validation library we use, seems to be missing some refs in the Azure definitions. I'm trying to find a fix.
    Sergey Tihon
    @sergey-tihon
    @MikeRalphson thank you, should I create Github issue for this or you already have one?
    Mike Ralphson
    @MikeRalphson
    Yes we already have issue #351
    Mike Ralphson
    @MikeRalphson
    We've launched an Open Collective fundraiser to help cover the hosting costs of the openapi-directory. If you find the directory useful, or integrate with it, please consider donating. Thank you. https://opencollective.com/openapi-directory