I am facing issues with cached/stall collection items
Steps to reproduce:
Create a mock server with an empty collection (via Postman Client)
Add request items with example responses (via Postman Api)
programmatically call POST to /collections/collectionId/requests
programmatically call POST to /collections/collectionId/responses?request=requestId
I do the above 21 times, i.e. creating 21 requests with example responses.
Reset the collection (sometimes I change the collection name with the PUT request)
Repeat step 2 (here is when the items compound, i.e. as if the PUT to reset the collection did not work)
Verify the collection state
GET /collections/collectionId
Observing the items returned for the call at step 5. they seem what they should be per the last created requests
Observing the items in Postman Client, they just compound and if I attempt to delete any of them I get on the UI the following pair of messages:
requestName was deleted successfully.
Unable to delete request
If I call /collections/collectionId I now receive a response with no items, although they still appear in postman client and are callable via POST postmanMockServerUrl/requestName
not sure this is an UI problem, or caching one, but this worked seamlessly just a week ago or so.
I only am using the Postman API. I use the postman client just to validate the results. I can see on a PUT /collections/collectionId that the items previously created remain in the client, whereby I try to delete them manually from the postman client and seeing the errors above, these ghost items just remain there. Even if I create new ones they collection just increase in size with the new ones and the “ghost” ones, really strange behavior.
My only way to “reset” all this is to delete the collection entirely - then delete the mock server associated with it and then recreate them…
If I open the collection in a different browser, at first I see it in its correct state, once I open a request it somehow refreshes and adds on the rogue requests? Really bizarre.
Could you help out here as it’s related to the Postman API.
@supply-technologist8 Can you update the original post, please? It’s missing a lot of the context and details that you mentioned when raising the Bug Report.
Hi, Cris!
The first thing I noticed in your description: if you want just to update the name of the collection, please use the PATCH endpoint, not the PUT one. The PUT is intended for other usages (like replacing the whole collection).
In addition, can send the bodies of the POST request and responses so I can check if something is wrong? Just change or mask the sensitive information.
Thanks!
Thanks for your reply, good point on using PUT wrongly, although the problem appears even if I do not change the name just reset the collection items. Would there be a DELETE collections/collectionId/items ?
{
"name": "test",
"responseCode": {
"code": 200,
"name": "OK"
},
"headers": [
{
"key": "Content-Type",
"value": "application/json"
}
],
"text": "{"anObject":"in the value of this text object I provide the response body json string content, so when I request the item I can see it in the response body"}",
"language": "json",
"requestObject": "{\"method\":\"POST\",\"url\":\"https://my-mock-server.com/urlsegmentpath/test\"}"
}
I was advised by @danny-dainton in a different thread that when creating mock requests/responses I need to provide a header - k: Accept v: application/vnd.postman.v2+json
while reading through the docs Postman API documentation it’s been said to use - k: Accept v: application/vnd.api.v10+json
for an end user like me what would be the difference between the two?
When moving from V9 > V10 of Postman there was a change in the way that APIs are created within platform.
To allow for either of the new and old versions to be created via the Postman API, that header (application/vnd.api.v10+json) is used when calling the API specific endpoints.
With the (application/vnd.postman.v2+json) header, there are some routes that are only currently on version 2 of the Postman API and without using that header in the request, those wouldn’t work.
For more granular details of these, @aerospace-geoscient2 would be able to expand on the information.
Hi, Cris!
The application/vnd.postman.v2+json header was something temporary we were using in some specific endpoints, like the old collection individual items API. Now, this API is public in the regular Public Postman API (here), and the header is not used anymore.
Related to the application/vnd.api.v10+json header, it’s there only for the API endpoints, to distinguish if you are working with APIs created in Postman v9 or APIs created in Postman v10. Eventually, the v9 endpoints will be removed.
so would it make a difference to me if I create request and example responses with one or the other header value, feels right to use the latest and greatest?
You don’t have to use any header to create requests and responses, the v2 header is not used anymore, and the v10 header is just for the /apis/ endpoints (and it will be removed eventually).
If you pass a header, it will be simply ignored in the collection items API.