Reuse the same request inside several collections

[KumG]

Is there a way to reuse the same request in several collections ? I didn't find how.

For example, I need to call a login method before any other method call, and I want my collections of tests to be independent. If I duplicate the login request, I will have to edit all the requests if I need to change something.

[sleisd]

+1

[geevb]

+1

[jstafford5380]

+1 It could probably be implemented using a "reference" approach. For example, for me, an ideal way to set up tests is to have a "tests" per endpoint which are just a way define how an endpoint gets called. Then in a test collection, you can pull in "references" to those per-endpoint requests as a "step" and build a chain of them to create a "scenario".

I think the challenge with this would be addressing the cases where you want the core of the "step" but also have the ability to modify one or two things about the step to fit the scenario without affecting the original, but also retaining the ability to receive changes from the original without overriding your override.

[daverondell]

+1

[xuyenauto]

+1 and waiting some good news for that function.

[waynebsx]

half a decade almost past and still no way to reuse a set of request in a DRY fashion. I find this the most frustrating thing with postman, means introducing repeated request and soon becomes unmaintainable. I've seen and tried working around with test hooks and eval func but that is a real hack.

[JohnArrowwood]

Word of warning: other tools will soon support this feature. If Postman does not find a way to support it, it may find itself replaced by a newer, more feature capable tool.

On Fri, Jan 10, 2020 at 12:00 PM Wayne notifications@github.com wrote:

half a decade almost past and still no way to reuse a set of request in a DRY fashion. I find this the most frustrating thing with postman, means introducing repeated request and soon becomes unmaintainable. I've seen and tried working around with test hooks and eval func but that is a real hack.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/postmanlabs/postman-app-support/issues/1535?email_source=notifications&email_token=AB3XLRKX5ZVG2OKXWBDD46DQ5CSTXA5CNFSM4BTAAD7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIURSGI#issuecomment-573118745, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3XLRPUOL7IFXNKNQRRIRTQ5CSTXANCNFSM4BTAAD7A .

[ihasaKAROT-nl]

Im with @JohnArrowwood and @waynebsx here. Im currently testing around 100 endpoints with endpoints, end-to-end, bdd-scenarios and miscelaneous tests in seperate folders and flows. Each folder also has a pre- and post-folder. This comes down to over 700 tests just for these endpoints, so on average I HAVE to duplicate every request about 7 times.

The big problem is that I have atleast 500 endpoints to go. I dont look forward to using postman for this if this does not get implemented any time soon.

[samsamm777]

Postman is not fit for purpose without this feature. I cannot comprehend having to create 100s of duplicate requests for each test scenario to workaround this inadequacy. Please implement this feature.

+1

[filipehb]

+1

[corwestermaniddink]

In Jmeter (yes it can be used as a functional integrationtest tool, not only for loadtesting) you can do this for along time now. With the so called Module Controller and also through a user-interface.

I like the schema way, because then you could also implement a "given-when-then" scenario's in to Postman, what supports the business to understand which testcoverage is in place.

In this topic I read different requests:

1. Just a way to put all requests in main collection(s) and create flows based on that main collection(s) in other collections. (Like module controller in Jmeter)

2. The schema way that is now introduced and developed in Postman, so it's possible to create a more functional way of different kind of tests (from 1 till a chain of systems).

[pbarnum]

+1

This would be a very welcomed feature. It doesn't make sense to me to separate requests into a collection based on "flows" especially working with micro-services.

[q-oriol]

+1

[riddy]

+1

[olapiv]

+1

[Gaket]

Here is a 116th comment for a similar case.

I'd like to have some flows in collections, so my colleagues understand some common flows. Of course, common flows contain some common requests that I wouldn't like to replicate over and over again.

[prashantagarwal]

Hey Everyone, I have created a template collection to reuse/reference a request in a different collection. This uses pm.sendRequest to fetch the request using Postman APIs.

I am also working on an extension of this idea which will let you chose requests from a different collection and run them in a defined order. This will be helpful for scenarios where you have a collection with all request but you want to tests different request flows.

[bbottema]

Wow, this is almost 5 years old now

A Runner should really not be linked to any specific collection, but simply allow you to select the requests you need, be it a whole collection or individual requests. Being able to create new collections based on requests from other collections obviously is interesting but seems to be a slightly different use case to me.

Really this is exactly the same issue with having files in a folder on a Windows system, when really what you want tags. Instead of Collections, I would like to be able to tag requests and whatever tags I defined will simply appear like folders / collections. This would elegantly solve both use cases.

[Justinohallo]

Has anyone tried to use the template collection referenced here: https://explore.postman.com/templates/7907/reusing-a-request ?

It takes 1 minute for each request when I use it. Wondering if anyone else is experiencing this as well.

[bbottema]

Yes, you need an API key and live connection to the Postman servers and the UUID of the relevant Collection. Finally you need scripts to actually reuse a request from another collection.

It so happened that Postman servers were down when I tested it and suffice to say this solution was not satisfactory.

[Justinohallo]

I have the set up working (the documentation is very weak, took me some time to figure out the steps to acquire the UUID for the collection I wanted), but every request that I reference takes nearly a minute to complete. The idea of chaining these together in a collection to test seems tedious at best. To test a simple user flow would take minutes as each request finishes.

I think the most elegant solution is to simply write your requests for each user flow from scratch. There is no efficient way to re use requests at the moment.

[leoroh]

+1. My apis also need to completed login and few other flows. Can not duplicate each of those in my 40+ features collection

[ChristianSauer]

OK, I was totally fed up by this and switched to tavern, and it'S much better at reusing requests. It has other warts, but it beats Postman unfurtunately. I really tried to make postman work for my testing scenarios, but it's just not workable without easily referencing requests.

[Justinohallo]

I have not tried Tavern, but am at nearing the end of the line with Postman. Cannot understand why this functionality does not exist after this thread was opened 5 years ago.

[bbottema]

But I don't understand why either, right. Postman is focused on helping customizing a complex request and save it because it's a lot of / meticulous work. Then it won't let you actually reuse them across Runner setups. Such a strange oversight. I wish the devs could shed a light on this and present some roadmap for this subject.

[Justinohallo]

@a85 - any comment?

[kinlane]

I can't speak for Abhinav, but I can speak to the fact that the team is very tuned into this need. The full announcement is coming shortly so I don't want to go into detail, but we have alluded to it in a couple webinars and talk already so I should be cool....but, we are heavily investing in Postman on the web. Meaning in an upcoming release you will be able to make calls using a web client. This work is part of four years worth of work to unwind the state of automation with collections spanning both desktop and the cloud.

I know that it seems trivial to unpack a single request in a collection, and allow for reuse, but doing this in an application that is primarily desktop, and has primarily evolved this way across over 11M users isn't trivial. Ensuring everything in Postman has a URI (including individual requests) is a major step to unwind some of this legacy and move towards what is being asked here.

All I can say is that a single request as as atomic unit of the API lifecycle, and how it gets defined, optimized, and reused across operations is an extremely important aspect of our road map. Doing so is taking a significant amount of unwinding of historic practices and desktop constraints. When the announcement of "Artemis" comes out I expect all you to be as vocal on the feedback loop for it as you've been here, helping us get to where you / we envision.

This topic is extremely important to me, which is why I have subscribed to, and have been watching the conversation, but until you have concrete features to reference it is tough to properly respond.

[ChristianSauer]

@kinlane I am not interested to run Postman in the web at all. Yes, its totally 2020 but my clients have stuff in VPCs, internal k8s clusters, have data privacy problems etc. so I am not going to add another web tool to the pile of crap I have to try to get through their approval process. I want to reuse requests in my collection, which I can shove through my CI/CD pipeline to get a GO / NO GO and be done. I realize that Postman makes no money off me in this manner so I think it's just that me and Postman will part ways for now

[kinlane]

@ChristianSauer not telling you that you have to use the desktop, web, or CLI. Up to you. But I am a little lost how us leveraging web infrastructure to provide URIs for collections and individual requests wouldn't help you in a VPC, internal K8s, and pipelines? How do you pull Newman into the pipeline? How does Postman help you manage your collections (and individual) requests using a public or private network. Do all your package managers live 100% on-premise? What is the relationship between your private collections (and individual requests) and Newman. We have GitHub sync (bitbucket/gitlab coming), so it seems like our work to unwind the complex web of what is a collection, how it gets used and reused, and more importantly referenced with a URI and reused across the API lifecycle would be beneficial to your work. But maybe I'm not understanding your world. Anyways, Good luck! Also wanted to add that we aren't about making money off our customers, we acknowledge there will always be the free layer of users, as well as the open source offerings like Newman. Cheers!

[corwestermaniddink]

@kinlane I think we need some details about how this going to work with a "Postman on the Web", to know how this is gonna integrate within in our CI/CD pipelines?

I agree with @ChristianSauer that if there is a need to run a Postman collection through a Postman Webservice API on the internet so that we can have access to a re-use of requests functionality, that we are not gonna do that. Why? Just simply the fact that it is a API outside our control. That is not what you want inside a crucial piece of process like a CI/CD pipeline, certainly not for something that could break the release in that pipeline.

But maby @kinlane you ment something else with "Postman on the web", enlighten us please :)

[kinlane]

I am just saying, "Ensuring everything in Postman has a URI (including individual requests) is a major step to unwind some of this legacy and move towards what is being asked here."

That collections now have a URI, so that it can be executed in a web client. Now that collections have a URI, let's have a conversation about what is the best path to get artifacts into your pipeline (large or small). I am not saying you have to use the web client, or the Postman API. All collections are already available via the Postman API, so using the requests they possess to dynamically generate derivative collections, running as monitors, or in pipelines is already possible via the API--it just isn't native in Postman, or in Newman.

Happy to prime this conversation with some questions I am asking myself as part of internal discussions:

• How do collections or other artifacts currently get into your "local" pipelines. Ie. git sync, package manager, other? How does Newman get into your pipeline?
• We have a sync OpenAPI to GitHub, and Bitbucket / GitLab coming. Would sync collection to Git help deliver artifacts?
• Or is having a package manager (NPM, Artifactory, etc) needed? A collection could be built to accomplish this today.
• If you are reusing requests, do requests live as references to each other, or fully hydrated requests as the artifact is generated, synced, packaged, and published.
• Are we just using JSON $ref between collection? <-- The URI pattern(s) will play a key role in defining this. relative? absolute?
• If we are reusing requests, and collections are derived from OpenAPI / Swagger, are the references back to OpenAPI or collection?
• We currently validate all requests in collections against OpenAPI truth, how does this impact request reuse across collections? What gets validated.

A request is historically just a JSON object in a larger JSON object that can exist across the desktop, git, and the web. There really is no unique identifier, sync or change management infrastructure to enable reuse. Now it has a web URL, let's now do the work to define how that gets generated, versioned, packaged, shared, synced, validated. Let's expose each individual Postman request as a first class resource that can be referenced and reused across all collections.

[pbarnum]

I believe this might be getting a bit off topic...

[kinlane]

Sorry if it feels that way. But having a uniform resource identifier strategy will be essential to "Reuse the same request inside several collections". How else do you reference? Reuse? Happy to expand each bullet to help demonstrate? Answer specific questions?

I am just looking to help defend the hard work the team has been doing to get the platform to a place where we can work to satisfy this request, and articulate the scope of the challenge. Let me work on a collection to demonstrate what is possible now, and I will iterate once the web runner is released in beta -- maybe that will help? Hit me with any specific questions.

[kinlane]

To help connect the dots a little more...consider this OpenAPI for the GitHub API which heavily uses $ref for "operation" reuse - which is very much what is being asked for here with "request" reuse - https://github.com/octokit/routes/tree/master/openapi/ghe-2.21

You can integrate this into the pipeline, just as is being asked above using HTTP, SSH, Zip, or API, but what is the URI guidance for how you traverse and "reuse" operations? Do you hydrate all of them as they get applied by pipelines? Which protocol do you use? (all my questions above)

My point is, the scope of the conversation is pretty large, and something being tackled within OpenAPI and Postman community. OpenAPI 3.0 implemented components to drive reuse of not just "operations", but other elements. Do we borrow from this for "request" reuse? There are a lot of questions to be answer before we can answer this issue, but we are closer than we ever have before to answering, and before we move forward some more there are a number of other questions that need answering--just looking to get those from community discussion.

Hope that helps. ;-)

[pbarnum]

Perfect, and thanks to the team in getting this feature out for the rest of us.

I purely use Postman as a way to manually test APIs and would like to use it for for testing different flows (again, manually). Everything I do automatically works through a python framework.

I would like some of my endpoints to reference others for things like automated login/authentication of a user before accessing restricted resources. Another example would be to run a payment flow from cart to order to payment to refund.

[kinlane]

A pretty standard usage of Postman. Very interesting use cases (automated login/authentication & payment flow from cart to order to payment to refund). I'll keep it in mind for demonstrating how you could define a reference collection for each of these scenarios, and then automatically generate a Postman collection using the Postman API, and publishing to Github. This is all doable now.

These "workflows" collections are just derivatives of the primary "reference" collections, so the workflows are always generated or compiled from the requests within a primary "reference" collection. The hard work will be to figure out best way to sync with Git, publish to package, or other to get the resulting artifact locally for pipeline run.

I'll see if I can pull some examples together to show what is possible now, and help inform the road map to get us to where Postman natively provides a solution in the desktop or web app, as well as Newman.

[Justinohallo]

@kinlane If you could provide some examples of the workflow above, that would be great. I too am attempting to create "User Flows" in a similar manner, to which I would hand off to my Front-End developer as confirmation that the end points are working as expected. It would be great to have the primary reference, where all endpoints are defined, and then a series of Work Flow Collections . A workflow collection would describe, for instance, logging in, fetching user data, and conducting CRUD operations on that user.

In essence, I want to chain my requests to reference a primary collection of requests, and achieve all of the user flows possible in my Front-End without having to manually create a new request for every single collection. I want it to look and feel exactly like how the Runner works right now, but with the ability to pull in a list of requests from a primary source.

[kinlane]

I really like this "I want it to look and feel exactly like how the Runner works right now, but with the ability to pull in a list of requests from a primary source." This is exactly what I'm talking about above. I am trying to understand how to design / define the references between the primary collection and the derivative and how it works. Working to answer a few questions: Are they generated? Are they just using $ref and the tooling processes?

Right now it would have to generate full Postman collections as the derivative so they can be run, but they should be disposable. Eventually it would be better to have Postman collections natively use $ref and refer to primary source, allowing for reuse.

I will work on some more thoughts and POC on how to do this with the current Postman via the API. It won't be smooth and everything, but it could set the tone for what is needed in the app. Thanks for expressing interest.

We just launched the new "Agent" I spoke of above to support Postman on the web. The roadmap for this includes web agent, and running collections other places. This work will drive much of the groundwork to power the re-use of collections.

• Introducing the Postman Agent: Send API Requests from Your Browser without Limit

[Totti10as]

Hi @kinlane, I didn't manage to understand with all latest correspondence here, is the "Request reuse" feature is ready for release on WEB / Desktop client?

[kinlane]

@Totti10as unfortunately not yet. there are some really lofty and heated debates going on internally about it works. I'm hoping soon. It is top of my list, and I'm lobbying hard.

[Totti10as]

@Totti10as unfortunately not yet. there are some really lofty and heated debates going on internally about it works. I'm hoping soon. It is top of my list, and I'm lobbying hard.

Ok, got it

[corwestermaniddink]

@kinlane In my opinion this gonna be a dealbreaker to proceed with Postman in general. To not have the ability to re-use requests takes allot of maintenance and extra work that we don't have if we choose other api-test tooling.

Even if this is not possible on GUI level, but just on javascript level would make a huge difference.

Also I think it's a huge business opportunity, to have another extra real sellable feature. The api test world is not standing still you know ;-)

[kinlane]

Where there is no direct way in the app to select a request in a collection, and reuse it currently, it confounds me this thread continues in the direction it does. There has been much work in this area, and continues to be:

1) You can generate multiple collections from the same OpenAPI or Swagger truth for different purposes (ie. mock, docs, test). "Reusing the same request in multiple collections". 2) We have moved to the web, producing a canonical URL for APIs and collections. 2) Each individual collection and request has a unique ID, and Postman has an API for adding, updating, and removing collections.

I am just stumped that this would be a "blocker" and "deal-breaker" -- this is the API universe folks. We develop and innovate on top of APIs to show what is possible with a platform. Is there some reason you don't build collections that demonstrate what you would like to see in the interface? I am regularly dynamically building collections from other collections, OpenAPI, and API discovery mechanisms -- as I did with this Salesforce collection builder.

The reuse of requests conversations continues within Postman. Moving to the web, using OpenAPI / Swagger as source of truth for requests are the most current movements. We are now working on internal and external references for schema (swagger, openapi, or collections), and trying to determine the best patterns across 12 million developers.

I would love to see the reuse you are so badly in need of as a collection using the Postman API -- it will help me build my case internally as part of road map prioritization.

[andyg101]

@kinlane All of that work sounds great but I think there is a simple point here. If you have a set of API calls for your test flow perhaps with some data set up steps that are repeated over and over you just don't want to be duplicating those requests it is not DRY. I have some scripts with circa 30 requests to get a system into a state where I want to test it and that results in a lot of duplication. What people want is a simple solution to re-use requests across collections in the GUI. If I have ten tests with the same setup then that gives me 300 requests to have to maintain that all do the same thing.

Yes you can do things with the pre/post request scripts, setNextRequest and so on but even as a software engineer / coder I have found this a bit fiddly and the results are inconsistent between the GUI and running with Newman. Additionally the API / platform web stuff is great but not all organisations want or are able to publish their APIs in this way.

SOAPUI has a feature I believe that literallly allows you to select test steps from another script and re-use them, that is the use case I believe people are talking about here.

[kinlane]

I get what is being asked here completely. I am just stating I don't think folks are considering the big picture of re-use (ie. OpenAPI as truth of that reuse). How difficult what is being asked is across 12M use cases, and I am unconvinced of it being a blocker, and something folks will walk away from postman from if they can't do (which folks love to throw out). Each request has a unique ID and there is an API reuse. Each request has an OpenAPI truth, and you can reuse across collections, and even validate that reuse -- if it is something that will push you to walk away from without showing a single use case via API, I am left feeling like your isn't a real problem.

This is why APIs exist to demonstrate what should be possible in app. It just is frustrating to be working overtime showing many different use cases to my team to influence the future of the UI, only to have people say "I am leaving cause you won't do this" (when we are doing it), without demonstrating their use case. It's cool. I'll keep doing the work and influencing the road map.

I'll say it again, and see if it sticks, "there is reuse of API requests right now" It is done with OpenAPI + Swagger -- then you can generate multiple mock, doc, and test collections from those "truths". You can validate those if they break, and regenerate them if they break. This thread is ONLY focused on collection to collection reuse. Show me a use case on why this is the right way, and I will influence the road map. I am looking at the big picture, this thread is just a single slice of that picture.

[kinlane]

Now that we are on the web. I am focused on $ref usage across OpenAPI, and leveraging of components object in OpenAPI and across OpenAPI -- multi-file support for referencing of requests. Which would trickle down to this slice of the reuse pie and give y'all what you are looking for in the UI. So bonus points for any $ref use cases of reuse.

[a85]

@andyg101 The reason we have been cautious around this is that "reusing" creates dependency graphs between entities. Building reusable requests like the way has been described in this request not only involves referencing but also managing these graphs. We haven't done this yet because then sharing, debugging, managing these graphs becomes a higher level problem. Another problem is that not only do these reused requests will be referenced but will also change between collections.

Postman's ease-of-use comes from the ability to run things quickly without having to configure or install a huge set up.

We have been looking at usage patterns and using specifications and fork/merge workflows or using find/replace or using collection level scripts helps manage the notion of reuse in different contexts. This is the same issue around code re-use and we are tackling that too.

One example to illustrate that incidental complexity is the "environments" feature. That was built for variable reuse. Now, every single time, when people have to share a collection with somebody else, they also have to remember how to share an environment or maybe multiple environments. This has become an explicit step and it creates additional failure points. We have learnt a lot from this and we will be baking this in the design of collection request reuse as well as code reuse.

[andyg101]

Just some responses. I'm just looking to understand what you are getting at, I have used Swagger a little but I wouldn't say I'm an expert.

I get what is being asked here completely. I am just stating I don't think folks are considering the big picture of re-use (ie. OpenAPI as truth of that reuse). How difficult what is being asked is across 12M use cases, and I am unconvinced of it being a blocker, and something folks will walk away from postman from if they can't do (which folks love to throw out). Each request has a unique ID and there is an API reuse. Each request has an OpenAPI truth, and you can reuse across collections, and even validate that reuse -- if it is something that will push you to walk away from without showing a single use case via API, I am left feeling like your isn't a real problem.

I don't understand what you mean by showing a single use case 'via API'. Can you clarify for me please? I think my use case is fairly simple. Let's say I have a request createFoo (I just happen to be using graphQL but I guess it could be a normal rest endpoint). I need to run the exact same request in 500 different test scripts that I have as separate collections. I don't want to maintain it in 500 places if my graphQl API changes. At the moment I'm exporting this to a collection json file so that I run these tests using newman in my CI tool. How do I do this using Swagger AND have the ability to run the same collections locally in the POSTMAN UI?

I have seen various solutions for this, including what seems to be the best where you have a setup folder in a single collection and you use various setNextRequest calls to run this folder before each of your tests. This would probably work, but I don't really want to bundle my tests into a single collection like this and relying on scripts interacting with each other at multiple levels in the collection heirarchy is fiddly and error prone IMO.

This is why APIs exist to demonstrate what should be possible in app. It just is frustrating to be working overtime showing many different use cases to my team to influence the future of the UI, only to have people say "I am leaving cause you won't do this" (when we are doing it), without demonstrating their use case. It's cool. I'll keep doing the work and influencing the road map.

I think I've explained my use case above. If you could give me a bit more of a steer on how I would use Swagger to do this I can have a go at that.

For reference the feature of SOAPUI I mentioned is documented here: https://www.soapui.org/docs/functional-testing/modularizing-your-tests/

[ghost]

+1

Re-use of a request or folder in the same or outside a collection would have great benefits for the maintainability of collections. Examples as also mentioned by @andyg101 are also applicable to me - the execution of for instance login (cross collection) and list/validation requests receptively in one collection to verify transactions executed earlier - are both regularly used practices. The setNextRequest could be a workaround - but is entirely non-transparent in ui and leads to a lot of coding to follow a flow (back and fort).

Our API guidelines enforce a standardisation of error handling (api key, version, bad input validation, mime-type checks etc) , which should be applied on all our APIs (collections), this validation has to be copied nowadays across all of the collections/methods, while test-cases are 100% the same.

Another use-case of re-using is with the use of a subset of collection for monitoring purposes. Interlinking would allow to create a collection with 'virtual' requests (or folders), which allows to use 1 collection for testing (full scope) - and 1 for efficient validation in monitors. A setup which is not supported at the moment and leads in copying collections for monitoring purposes with a result of inconsistency over time.

[rpkrupali1]

+1