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.

[Piioupiou]

+1

[kudinov-fedor]

There is a possible work around of this problem within postman collection.

You can add some technical requests, which settle list of requests in globals (e.g ["request 1", "request 3", "request 5"] ), and during execution you need to iterate through this list to calculate next request and place it in postman.setNextRequest() dynamicaly in requests "Tests" section.

Here is an example to demonstrate implementation of this method:

https://www.getpostman.com/collections/37c956015760dc49fb7b

reusable requests.postman_collection.zip

[liuzhiguo630]

+1 I think if it could create a soft link of a existed request, this problem will be resolved.

[jacklqt]

+1

[mikecg]

+1

[ChrisGeorg]

+1

[yairbudic]

+1

[jebgarcia]

+1

[parthjmistry]

+1

[4Ply]

+1

[wdtracy]

+1

[gauravshetti]

+1

[pavankumar-dv]

+1 conceptually an ability to symlink folders/requests even collections to avoid duplication. i believe this is the major disadvantage for postman.

[chuck-wood]

+1

While setNextRequest is a viable workaround, it really defeats the strength of Postman, which is its GUI.

[calloc]

+1 Changing source template should affect all instances of the template.

[tflintio]

+1

[Ashley-Clementi]

+1

[Kal6]

Hi There I am a Test Automation Consultant, have been working on almost all popular tools in the market. POSTMAN is kind of cool tool to automate API testing but due to some of unsupported features which is becoming cumbersome. This feature is one of it which will be definitely a great feature if we can get this, because other tools provide a feature called library files where we can have reusable stuff and changes can be placed in one place and applies everywhere where we use this components so because of this unsupported feature we need to change all of our duplicated requests when ever changes are occurred causing more maintenance and effort and time consuming too.

I advice to address this to be implemented asap.

I really appreciate the POSTMAN supporting team if they could introduce this feature soon.

[Doube-SW]

+1

Just looking for the same feature. For testing purposes I broke down requests into small chunks, named them and reuse them in different scenario's. In this case it would be best to link them to a master instead. Would save a lot of effort maintaining such test scenario's.

[piersmacdonald]

+1

Reasoning: We have a service WidgetService with 8 endpoints of which 2 are publicly available. I'd like to use Postman to create the publicly facing API documentation. To do that I currently have a 'Public' collection and copy the endpoints from our WidgetService over. It would be great if changes in one could be reflected in the other

[ManikandanRajendran]

+1

It would be great if we have this feature as only re usability is missing in postman.

[stephan-simondshealth-com-au]

FYI

I just checked and we are following the right process by voting.... https://support.getpostman.com/hc/en-us/articles/115003270949?input_string=voting+on+github+issues

Regardless I checked in with Postman to see if this is still on their radar: https://support.getpostman.com/hc/en-us/requests/22752

I still hope this feature makes it into the product eventually, its a BIG pain on large projects....

[mehalick]

+1

[larsvinder]

+1

[Fincodr]

+1

[Robert-Hillary]

+1

[a85]

We are looking at allowing tests to be composed of multiple Collections instead of having a declarative/inheritance based model. Composition is something that we think is going to be more flexible. Along with this, we are also thinking about having external libraries being referenced as part of scripts so common things don't need to be re-defined everywhere.

[gauravshetti]

We are looking at allowing tests to be composed of multiple Collections instead of having a declarative/inheritance based model. Composition is something that we think is going to be more flexible. Along with this, we are also thinking about having external libraries being referenced as part of scripts so common things don't need to be re-defined everywhere.

So basically, 1 main test -> many collections (thats the idea ? )

[baylee]

+1

Tests aside, some form of reusable requests would be greatly beneficial for organization. For example, it is helpful for our API developers to see requests organized by microservice (e.g., different folders in a collection), while it is often helpful for API and client developers to see requests organized by user behavior flows. Copy-pasting requests into multiple locations doesn't scale well.

[gbetances089]

+1

[brcinho]

+1

[ChristianSauer]

Yes, it would be great for testing - especially if we could marry it with parameters. E.g. define some steps somewhere else, add them to your test and customize the moving parts via parameters (e.g. imagine that i got an id in the test and want to use it in the step)

[Snogren]

+1 was searching for how to do this and stumbled across this request

[jbiffis]

+1

[cesardka]

+1

I'm quite surprised that this feature wasn't implemented yet, but glad to know that you guys are at least aware of this demand

[aditki]

+1

[aditki]

I have a thought on how we can achieve this. I don't know if this works for every use case. Idea is to pre populate the requests we need to reuse in the collection files before running them. Postman saves collections, folders, requests in nested arrays. Because the order has to be maintained that indexes of the requests in a folder and folders in a collection are maintained. We can create an array of requests or array of folders in a separate JSON files and insert them into the collection files before we run them. thoughts??

[EbolaNerd]

+1

The one thing I'm missing in Postman that is available in SoapUI, is the ability to create a service definition, separate from the test case definition/implementations.

Each test case can then simply refer to the service definition and whenever the service definition changes, the test engineer only needs to change the definition one place, changes will then propagate to all the test cases that are using the service.

I like Postman better than SoapUI, but this is one "'feature" where SoapUI has the upper hand.

[awalland]

+1

[gtnardy]

+1

[pavelgordon]

+1

[klemens-u]

+1

[markwoon]

+1 for this as well.

I'd like to be able to call requests inline (e.g. a requests that cleans up the current request) and then have it continue on without having to mess around with setNextRequest().

[daveshute]

Yes. This. In many cases I've got a lot of setup and reusing calls. A way to insert a request into a stream rather than reset position would be wildly helpful.

[sandeep609]

+1...

The way collection runner is organized, users have the capability to run only

1. A collection. (ex - myTeamCollection)
2. A folder within a collection. (ex - useCaseA)

For example useCaseA has around 8 individual requests and there is a login and a logout request which could be re-used across other folders within the collection, currently there is no way to re-use requests

Work-arounds we have are...

• Duplicate the requests across many folders. (to make sure we can use collection-runner...)
• Have the folders organized in a different way so that we group common capabilities rather than based on use-case. (In this case we loose the power of collection runners, rather we just have to manually execute individual requests based on the use-case...)

Each of the above approaches have draw-backs, so one way we can think about is to have request-shortcuts where we can re-use requests in different folders so that folders in itself have all the required request to run as part of the collection runner and at the same time not have redundant request thereby following the DRY principle...

[a85]

Everyone, this is part of a much larger initiative but we are introducing the ability to define APIs in Postman using schemas. You will be able to document schemas for both requests and responses using whatever format you typically use. Postman will then take this as another input in generating docs, building mocks, or adding tests. It looks like this:

Eventually, this will also allow you to link multiple collections to the same schema and reference individual schemas for each request inside a collection. We feel this is a much more scalable way to handle reusability issues. Essentially this is a kind of request inheritance but instead of doing this from one request in another collection, you'll be doing this through a schema. We will start with OpenAPI and RAML in the beginning but will be extending this to GraphQL and the Collections format itself.

We'd love your feedback!

[JohnArrowwood]

I'd have to try it out to see if it meets my needs.

But I can tell you my use case, and maybe that will help?

We have a fairly complex authorization system. In order to test the authorization logic, a bunch or records have to be set up in the database prior to requesting an authorization assertion. That setup work is done through a series of API calls, as is the post-test tear-down.

The goal is to define the API calls ONCE, in one location, and then string together sequences of those calls in order to accomplish specific and repeatable tasks, such as setting up for and testing this test case, or setting up for and testing this other test case. Since certain sequences are fairly common, it would be nice to also define a series of calls, and be able to include that by reference, as well.

If this were a programming language, we would be asking for function calls. Imagine a programming language without the ability to define user defined functions. Imagine how frustrated you would be. How dirty you feel replicating code all over the place. That's how I feel when I try to get stuff done using Postman.

As you build this new feature, please imagine a programmer looking for the ability to define things once and use them everywhere, and make sure that the user will be able to understand how to use the newly created feature to accomplish exactly that.

On Sun, May 5, 2019 at 6:11 PM Abhinav Asthana notifications@github.com wrote:

Everyone, this is part of a much larger initiative but we are introducing the ability to define APIs in Postman using schemas. You will be able to document schemas for both requests and responses using whatever format you typically use. Postman will then take this as another input in generating docs, building mocks, or adding tests. It looks like this:

[image: Screenshot 2019-04-30 14 02 13] https://user-images.githubusercontent.com/653409/56995066-8d635400-6b55-11e9-9720-0888d91e4e82.png

Eventually, this will also allow you to link multiple collections to the same schema and reference individual schemas for each request inside a collection. We feel this is a much more scalable way to handle reusability issues. Essentially this is a kind of request inheritance but instead of doing this from one request in another collection, you'll be doing this through a schema. We will start with OpenAPI and RAML in the beginning but will be extending this to GraphQL and the Collections format itself.

We'd love your feedback!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/postmanlabs/postman-app-support/issues/1535#issuecomment-489468005, or mute the thread https://github.com/notifications/unsubscribe-auth/AB3XLRJIBTXQAM2OTJURCFLPT5LQJANCNFSM4BTAAD7A .

-- John Arrowwood

[a85]

@JohnArrowwood Thank you for your comment. This helps a lot. We are aware of the issues that can come up while working with complex cases like the ones you are dealing with. The goal is to solve it in a way that is consistent with Postman's philosophy to keep things simple and accessible using a user interface.

In terms of executing requests or sequences of requests across multiple workflows, we are working on related ideas that @shamasis can shed more light on.

[markwoon]

@a85 This doesn't not seem to address the main issues discussed in this issue. Or at least, this doesn't look like it'll help me with my needs. I'll second @JohnArrowwood's requirements and would love to hear more about what @shamasis has in store (and better yet, what the timeline is for that).

[a85]

@markwoon For requests to be "defined" once, there needs to be place where Postman can conclusively say that "this" is the definition. The API abstraction is the first step in the system to create a place for definitions.

We CAN do it by saying any request can be referenced anywhere in any collection but it creates complex dependency mapping issues that will be a nightmare to debug and maintain. Postman has to walk the line between offering a comprehensible user interface along with providing reusable constructs. Programmatic abstractions are easy to define in one place but harder to debug and maintain over time. Even then, programming languages also define constraints on how things can be composed together (functional vs classes vs libraries vs modules) and we are building the vocabulary for reusability first.