It is pretty common for datacenters to support both http and https for web services, but the current schema seems to have only a single URL per service, and no way to say that both http and https are allowed. This forces clients to guess. In addition many web servers are configured to redirect http to https and use 301 as the redirect code, but this causes a POST to be changed to a GET which then fails in a very confusing way. There is no way in browsers for javascript to determine the redirect URL, so hard to manually handle the redirect.
It would be good long term if either multiple URLS were allowed per service, which would be a breaking change. Or maybe better, add a "https-available" field where the values could be "no", "allowed" or "required". Then the client could update the protocol in the URL to match their needs.
See
https://fetch.spec.whatwg.org/#atomic-http-redirect-handling
whatwg/fetch#763
It is pretty common for datacenters to support both http and https for web services, but the current schema seems to have only a single URL per service, and no way to say that both http and https are allowed. This forces clients to guess. In addition many web servers are configured to redirect http to https and use 301 as the redirect code, but this causes a POST to be changed to a GET which then fails in a very confusing way. There is no way in browsers for javascript to determine the redirect URL, so hard to manually handle the redirect.
It would be good long term if either multiple URLS were allowed per service, which would be a breaking change. Or maybe better, add a "https-available" field where the values could be "no", "allowed" or "required". Then the client could update the protocol in the URL to match their needs.
See
https://fetch.spec.whatwg.org/#atomic-http-redirect-handling
whatwg/fetch#763