I wanted to enrich my library contribution with pr...
# wiremock-cloud
s
I wanted to enrich my library contribution with proper payloads, but I seem to be missing something. The API was imported fine => I click record => enter the actual API target URL => hit start => perform the apt curl => response of { } I am basing myself upon: https://docs.wiremock.io/recording-stubs/#:~:text=Once%20you%20have%20logged%20into,the%20target%20URL%20and%20hit%20.&text=This%20request%20will%20be%20proxied,json%20and%20the%20result%20captured.
t
Strange, it worked as expected for me
I wonder if the target API just happened to give a spurious response when you were recording?
s
Odd, I just tried again with the same results.
t
Same bad result?
Could you try with
-v
on the curl command and paste the output?
s
verho@home-pc MINGW64 /c/Development/api-template-library (foojay-discoapi-template) $ curl https://3lg1y.wiremockapi.cloud/disco/v3.0/supported_terms_of_support -v * Trying 44.204.248.166:443... * Connected to 3lg1y.wiremockapi.cloud (44.204.248.166) port 443 (#0) * schannel: disabled automatic use of client certificate * using HTTP/1.x
GET /disco/v3.0/supported_terms_of_support HTTP/1.1
Host: 3lg1y.wiremockapi.cloud
User-Agent: curl/8.1.2
Accept: /
* schannel: remote party requests renegotiation * schannel: renegotiating SSL/TLS connection * schannel: SSL/TLS connection renegotiated * schannel: remote party requests renegotiation * schannel: renegotiating SSL/TLS connection * schannel: SSL/TLS connection renegotiated * schannel: remote party requests renegotiation * schannel: renegotiating SSL/TLS connection * schannel: SSL/TLS connection renegotiated < HTTP/1.1 200 OK < Vary: Origin < Content-Type: application/json < Matched-Stub-Id: dda0378b-5faf-468c-a656-891139bbf52c < Matched-Stub-Name: Returns the supported terms of support < Content-Length: 3 < { }* Connection #0 to host 3lg1y.wiremockapi.cloud left intact
t
Ah, you have a stub that already matches that request and it’s serving that as a response
If you delete the stub named “Returns the supported terms of support” then try again it should work
s
Ah ok, thank you. I thought it would update the existing ones if it already matched.
t
No, it won’t touch existing stubs at the moment.
s
t
What triggered that?
s
I did a couple of recordings in a row
And some are seemingly missing
there are some pretty large payloads in there
t
I can’t follow that link unfortunately. Could you send a screenshot of the UI error?
s
it recovers after a while, just very sluggish
t
We’re about to start some work to change the way we handle large response bodies
At the moment it’s all in memory, inlined in the stub, and the UI component loads it all
s
That's what I assumed
t
We’re going to set a threshold above which it uses file uploads/downloads
s
I was documenting https://api.foojay.io/swagger-ui#/ to improve my library PR
👍 1
t
Is there a URL you can share with me that I can use for my own testing?
Would be useful to replicate what you’re seeing so that we can use it to improve things in the interim
s
t
Thanks, please leave this with me
Yeah, 25MB payload. Think we’re not quite up to that at the moment.