I know that we can have examples in the drop down menu for each parameter in the openapi spec. This requires to select each example for each parameter.
I was wondering if it is possible to have a drop down menu for the endpoint that we can select the example and that example has the values for all parameters in that endpoint.
This is not supported - neither by the OpenAPI Specification nor in Swagger UI. Here's an existing feature request in the OpenAPI Specification repository:
https://github.com/OAI/OpenAPI-Specification/issues/1673
I tried swagger 3.2.2 by running a GET operation with few query params.
I find defaults values I set in REST API can't override in swagger UI. All the text boxes are read only, and drop-down of Boolean query param always sends 'false' though I select it to 'true'. It seems program default values are super hard-corded here. I was playing with swagger #ApiPram(..) to fix this but it didn't help me.
Did anyone ran in to the same issue I describe above with Swagger 3.x?
I start using Swagger UI 3.5.0 and fixed the issue
I'm importing a swagger specification file into postman to create a collection, at this point, works as expected and the collection is generated with all requests & sub-folders, fine!!. But when the api is updated, I need update the postman to update all requests based on the new specification. I can't find a action like "update" or something else. I'm trying import the new specification into postman and he say:
A collection APIName already exists.
What would you like to do?
Replace or Import as copy
a copy its a not feasible option, then I use replace and the existent collection is updated, but all tests, parameters, pre-req scripts are remove and I need reconfigure all again.
I'm missing something, exist a way to import & update a existent collection from a specification file, without losing existent tests & configuration?
thanks in advance!
Postman does not support this as of now. Link
Alternative I learned from this blog. In short:
Update your OpenAPI YAML/JSON files.
Import to Postman as a new collection.
Export the new collection from Postman. As JSON in Collection v2.1 format (recommended).
Using Postman API (Update Collection), update the existing collection with the JSON in step 3 as body. Make sure to update collection_uid accordingly.
Postman update collection API body sample:
{
"collection":
<------- YOUR EXPORTED COLLECTION HERE --------->
}
I have made a small tool to do this: swagger2postman: convert swagger to postman collection and update exist collection
The tool will combine new and old collection, when conflict, it will use saved in postman. The tool can detect update in query parameter, but not post body. It will keep all your collection and test cases.
There is no straightforward solution. There also probably won't be one for quite some time - the devs said it is hard to correlate old Postman requests in a collection with new requests generated from incoming Swagger file (or any other source of updates, for that matter).
You can do it outside of Postman, though. Postman collections are really just JSON data and can be manipulated as such.
Transform your Swagger file to a Postman collection file. (You can just import it and export it again, or use tools like Swagger2Postman if you want to automate. Save it as collection 2.0 or newer, that format makes step 3 a lot easier.)
Export your old collection in the same version
Merge the two JSONs in your preferred scripting language
Import the merged JSON back to Postman
I made myself a simple helper for step 3. It is fine if you are just adding more stuff to the collection (my case), but can't remove anything. If anyone has a more versatile solution, please, post it - I would gladly use it instead.
function execute() {
collection = JSON.parse($(".collection").val());
swagger = JSON.parse($(".swagger").val());
result = JSON.stringify($.extend(true, {}, swagger, collection));
$(".result").val(result);
}
<html><body>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<br>Collection: <br> <textarea class="collection"></textarea>
<br>Swagger: <br> <textarea class="swagger"></textarea>
<br>Result: <br> <textarea class="result"></textarea>
<br>
<button onClick="execute()">EXECUTE</button>
</body></html>
It seems that they have implemented this feature,
https://github.com/postmanlabs/postman-app-support/issues/6722#issuecomment-652929581
https://learning.postman.com/docs/designing-and-developing-your-api/validating-elements-against-schema/
You can paste your new schema in the API define tab and update it.
I'm trying to turn the Atom Publishing Protocol (RFC5023) in to a Swagger / OpenAPI spec to exercise writing those specs.
I ran into the following problem: in Atom there are different types of URIs, e.g. Collection and Member URIs.
My idea was to document it like this:
paths:
/{CollectionURI}:
get:
summary: List Collection Members
...
post:
summary: Create a Resource
...
parameters:
- $ref: "#/parameters/CollectionURI"
/{MemberURI}:
get:
summary: Retrieve a Resource
...
parameters:
- $ref: "#/parameters/MemberURI"
When I do that, swagger-editor claims that
Equivalent path already exists: /{MemberURI}
Those are different types of URIs that return different things when queried. I want to call them differently to document them individually.
Is there any way to do this?
Thanks!
EDIT:
The spec shows up just fine in Swagger-UI -- is this a bug in the editor or does the UI just ignore my error?
That's because the two paths can be identical. I understand that the parameters may uniquely identify them, but OpenAPI 2.0 (Swagger 2.0), 3.0 and 3.1 do not support full URI templates, and the path portion alone is inspected for uniqueness. So these:
/{foo}
/{bar}
are identical, even if foo must be a string, and bar must be a number. Please add your $0.02 on the OpenAPI Specification Repo as we're working on better path support right now.
I'm trying to turn the Atom Publishing Protocol (RFC5023) in to a Swagger / OpenAPI spec to exercise writing those specs.
I ran into the following problem: in Atom there are different types of URIs, e.g. Collection and Member URIs.
My idea was to document it like this:
paths:
/{CollectionURI}:
get:
summary: List Collection Members
...
post:
summary: Create a Resource
...
parameters:
- $ref: "#/parameters/CollectionURI"
/{MemberURI}:
get:
summary: Retrieve a Resource
...
parameters:
- $ref: "#/parameters/MemberURI"
When I do that, swagger-editor claims that
Equivalent path already exists: /{MemberURI}
Those are different types of URIs that return different things when queried. I want to call them differently to document them individually.
Is there any way to do this?
Thanks!
EDIT:
The spec shows up just fine in Swagger-UI -- is this a bug in the editor or does the UI just ignore my error?
That's because the two paths can be identical. I understand that the parameters may uniquely identify them, but OpenAPI 2.0 (Swagger 2.0), 3.0 and 3.1 do not support full URI templates, and the path portion alone is inspected for uniqueness. So these:
/{foo}
/{bar}
are identical, even if foo must be a string, and bar must be a number. Please add your $0.02 on the OpenAPI Specification Repo as we're working on better path support right now.