marcl's avatar
marcl
Occasional Contributor
9 years ago
Status:
Accepted for Discussion

Share APIs between projects

We currently have around a dozen composite projects, which all use the same set of API. The reason we use so much projects instead of a single big one is for performance reasons.

When an API change (adding a new method, adding a parameter, etc) we thus have to update the API of each of the projects manually. We currently work around that by using symlinks, but this solution is clunky at best.

 

To prevent that, we would like some way to "share" the API definitions between multiple projects, having the API described in a single place and useable by all other projects.

 

The choosen solution should be compatible with version-control systems (e.g. something we can submit / check out), so any employee with a fresh computer can simply check-out the project(s) and start working without any extra configuration.

3 Comments

Sort By
  • MattiH's avatar
    MattiH
    Staff
    9 years ago
    Status changed:
    New Idea
    to
    Accepted for Discussion

    Hi, 

     

    this is an interesting idea, however I want to avoid having references across projects.

    You write that one reason is performance, what number of APIs are we talking about?

    I want to find out if there can be another way to solve this.

     

    Best regards,

    Matti Hjelm

  • marcl's avatar
    marcl
    Occasional Contributor
    9 years ago

    We're talking about a couple dozen APIs (we are using ReadyAPI to test a system with lots of applications interacting with each other, and each application have some REST API allowing us to check its state and control it).

     

    But the performance problems are not due to the number of API, as far as I know. They are apparently due to the size of our projects (see internal defect SOAP-4680); But we also get performance problems on smaller projects (I'll send you a private message with the URL to a video I made for your support team regarding another issue, so you'll see by yourself).

     

  • kbw's avatar
    kbw
    Contributor
    7 years ago

    I like this idea, it's something that I've been thinking about too. It's not just a performance thing, it's also an organizational thing--test suites are pretty flat in a single project, so it's clunky to put different APIs that each might have a number of test suites for themselves all into a single project when most of their tests are exclusive of each other.  However, when those APIs do interact, either directly or indirectly, it would be useful to have access to the APIs from a central place instead of having to replicate and maintain them in each project.

     

    If SoapUI projects had more nesting ability of test suits, then that would even be enough for me, rather than keeping projects separate. That would make keeping test suites for separate APIs in the same project easier to organize (the current test suite structure is too flat for this). Actually... I'll look to see if there's such an enhancement request and log one if there is one yet.

     

    Edit: Just added the FR:

    https://community.smartbear.com/t5/ReadyAPI-Feature-Requests/Add-a-optional-quot-Category-quot-level-above-Test-Suites-in-the/idi-p/147606