Not sure if this is considered a <#CSUFRDVKN|>, bu...
# pactflow
k
Not sure if this is considered a #CSUFRDVKN, but I've been wondering... In case of bidirectional testing, its up to the provider to push their openapi specs to the broker, and record when a deployment has been made. Its a lot less work for the provider compared to consumer-driven. However, all our services use Swagger, which also exposes the openapi spec through an endpoint. Wouldnt be much less work still, if the pact broker could query the openapi spec directly from the environment? I imagine that the provider then wont have to do anything at all, except for maybe configure the url somewhere where to get the openapi spec from. Has there been any thoughts on this?
m
Do you mean swagger hub?
k
Oh no, did I reinvent the wheel? 😅 Going to check out swaggerhub now
r
I think he means the provider itself has an API that provides the OAS file.
m
sorry I was on my mobile when I read this. That makes sense Ron/Kevin
Wouldnt be much less work still, if the pact broker could query the openapi spec directly from the environment?
Yes, I can see why you would ask that. It’s not completely unreasonable, but that itself doesn’t guarantee the API implements the spec. That’s why we ask for test results (even if we don’t check what the results are themselves). It does raise some further workflow issues though - how do we trigger when to see if there is a new version of the spec? What if you deployed a breaking change and only after the OAS was retrieved in the target environment things were broken?
r
If it is using things like Spring and Swagger annotations, the OAS is generated from the actual controllers, so the generated spec represents that actual API. I think BDC is more for cases where the spec is written by one team and given to another team to implement.
m
Is it not possible to have scaffolded your code base with correct types (which would generate a “correct” OAS), but have no implementation for them? Or a buggy implementation of them?