I suggest you ...

Multiple APIs in one Github repository

It would be great to have multiple API files stored in 1 Github Repository. We have internal APIs that are documented separately, however we don't wanna have a separate repository in Github for each API.

113 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Nick DNick D shared this idea  ·   ·  Admin →

    22 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Emmanuel ParaskakisEmmanuel Paraskakis commented  · 

        This this is now a deployed feature, in Beta - please ping support@apiary.io if you'd like to try it. Fair warning, it'll be part of our extended GitHub Flow integration in a paid plan, eventually.

      • alberto sarubbialberto sarubbi commented  · 

        +1. the first time i tried this, i ended up overwriting all my API.

        an idea would be to use the subdomain name as the git file.

      • Anonymous commented  · 

        @Lukas, we (CS, a.s.) would definitely like to take part on betatesting this feature!

      • Kris KlevaKris Kleva commented  · 

        I'm doing a +3 on this one. It's really hard to manage a boat load of blueprints on github. I've got dozens of blueprints and a small army of API developers. You can get around all this making smart use of CI and the Apiary.io Ruby Gem.

      • VerachadWVerachadW commented  · 

        Is there any update on this request?

      • Brian WolfeBrian Wolfe commented  · 

        We need this feature also. Having to have an extra repository for each API's blueprint doc is inconsistent with how we use code repositories.

      • Far McKonFar McKon commented  · 

        Yeah, even if you just allow a developer to point different API's to different files in the same repo, that would be a huge help. IE, just a 'save apib as non-default file-name' in the configuration page, that would be a huge help.

      • steve bakersteve baker commented  · 

        This is a pretty big one for us. As a potential solution, would the following work:
        look in the repo for any blueprint doc
        take a convention based approach with:
        index, readme, default -> used as the main page shown
        other files go into a drop down / navigation, with a convention on ordering (a-z, semver, etc)
        any folders containing files would add layers so you could have:

        billing
        > 1.0.0
        > 1.0.1
        > 2.0.0
        workflow
        > 1.0.0
        etc
        > 1.0.0

        and urls would just be docs.yourapi.apiary.io/filename or docs.yourapi.apiary.io/folder/filename

        Then the workflow is kept simple, so you just follow the conventions, and commit
        and if you want more control on the navigation, you add a readme/index/default and have links in there?

        not sure if that fits with your thinking here or not?

      • Lukas LinhartAdminLukas Linhart (Admin, apiary.io) commented  · 

        Hi Mohan,

        unfortunately, there are no updates yet. We are unifying this concept with splitting blueprints into multiple files and being able to have non-text response bodies.

        I hope to give more details soon, but there is still no ETA yet.

        Regards,

        Lukas

      • Mohan BalachandranMohan Balachandran commented  · 

        We tend to keep APIs private until fully spec-ed out and implemented and the cost of private repos adds up quickly. Any updates would be much appreciated.

      • PJ KellyPJ Kelly commented  · 

        +1 - This would really help with documenting versions of our APIs.

      ← Previous 1

      Feedback and Knowledge Base