Splitting provider info and transports The

pact_verifier_set_provider_info

FFI call (here ) includes adding a default transport when setting up the verifier, but this makes integrating with the FFI awkward for libraries. Since Pact Spec v4, a pact file can now contain both HTTP and message interactions, and this is implemented by adding a transport for both HTTP and messaging via

pact_verifier_add_provider_transport

(here). The problem is that when the user is setting up a verifier, they want to specify 3 things: • The provider name • The HTTP endpoint • The messaging endpoint The FFI forces them to treat those as two things instead of three though, because specifying the provider name forces you to supply a transport. This creates an awkward API because there are three possible combinations for setting up a verifier: • HTTP only • Messaging only • Both HTTP and messaging Plus in future there may also be plugin-based transports, which creates a combinatorial explosion. You can kinda deal with this in library code by either storing the name up and only adding it once the user has either specified HTTP or messaging, or you can check if you've already added a transport when you add subsequent ones and call different FFI methods. That's what PactNet does here That's an awkward thing that every library developer has to implement though, and they may implement them differently. Instead I'd prefer if the FFI allowed you to specify the provider info without having to specify a transport, and then initialising the verifier and adding the transports are separated and easy to integrate with.

Good point. The

pact_verifier_set_provider_info

predates the changes required to support multiple ports and protocols for the same provider. It should be deprecated and a replacement added.

Thanks Adam, created: https://github.com/pact-foundation/pact-reference/issues/297