The 'servers' for each spec only lists test servers, not production URLs

[pimterry]

Describe the bug

The servers field of each spec only lists a single test URL for each API, instead of actually specifying the pattern of URLs used.

This is inconvenient, as some tools (such as HTTP Toolkit - I'm the maintainer) use the servers listed in the spec to recognise traffic to an API, and provide appropriate tooling for the API in that case.

For Adyen right now that isn't possible - nobody can use these spec for anything relating to traffic to Adyen production APIs, only to your test APIs (still useful, but very limiting).

To Reproduce

Look at any spec's servers, e.g. for the checkout API:

adyen-openapi/json/CheckoutService-v70.json

Lines 3 to 7 in 40452c3

	"servers" : [
	{
	"url" : "https://checkout-test.adyen.com/v70"
	}
	],

This just lists the test endpoint, where the actual production URLs according to https://docs.adyen.com/development-resources/live-endpoints can include https://[prefix]-checkout-live.adyenpayments.com/checkout/v70/.

Expected behavior

The specs should also include the pattern of the production base URL, using variables for the potentially variable component, for example something like:

"servers": [
  {
    "url" : "https://checkout-test.adyen.com/v70",
    "description": "The test API"
  },
  {
    "url": "https://{prefix}-checkout-live.adyenpayments.com/checkout/v70",
    "description": "The production API",
    "variables": {
      "prefix": {
        "description": "A string composed of a hex-encoded random part and your company name. Get the prefix from your live Customer Area under Developers > API URLs > Prefix"
      }
    }
  }
]

This makes it possible to use these specs for requests to Adyen production APIs, and for tooling to recognize traffic to these APIs.

[jlengrand]

Thanks for the detailed issue @pimterry. That sounds indeed reasonable (to me at least). What do you think @gcatanese, @rikterbeek ?