You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we set a single global environment on the HTTPManager, and then tie a number of defaults to it. This is convenient for simple setups, but doesn't work well if e.g. the client has a number of subdomains for different API sets that all want to share the same auth.
There are a number of ways we could go with this, but here's a brief summary of my current thoughts:
Multiple environments on an HTTPManager. For the base URL to use for requests constructed with relative URLs, we could either go with the first environment, or have an explicit defaultEnvironment. The first one is simpler, but means I can't configure a single environment without making it the base. The latter is more flexible, but would allow me to e.g. set a default environment that's not in the environments list. We could also just divorce the base URL handling from environments entirely and have it be a separate property, though I'm not particularly happy about this approach either.
The defaults that apply to the environment should be moved onto the environment object itself. This way I can configure the defaults separately per-environment. This means a separate per-environment lock, but that's probably fine.
Instead of HTTPManagerRequest.setDefaultEnvironmentalProperties() we'd have something like HTTPManagerRequest.applyDefaults(from:) (or maybe HTTPManagerEnvironment.applyDefaults(to:)).
Something I'm not sure about is how to handle multiple domains that should have the same properties, because keeping the properties in sync between environments when mutating them is annoying. We could give HTTPManagerEnvironment a whole array of domains instead of a single one. Another option is to have an option to "apply to subdomains" so I can just set up an environment for the root, though this approach is problematic if I want the default base URL to be a subdomain.
The text was updated successfully, but these errors were encountered:
Right now we set a single global environment on the
HTTPManager
, and then tie a number of defaults to it. This is convenient for simple setups, but doesn't work well if e.g. the client has a number of subdomains for different API sets that all want to share the same auth.There are a number of ways we could go with this, but here's a brief summary of my current thoughts:
HTTPManager
. For the base URL to use for requests constructed with relative URLs, we could either go with the first environment, or have an explicitdefaultEnvironment
. The first one is simpler, but means I can't configure a single environment without making it the base. The latter is more flexible, but would allow me to e.g. set a default environment that's not in the environments list. We could also just divorce the base URL handling from environments entirely and have it be a separate property, though I'm not particularly happy about this approach either.HTTPManagerRequest.setDefaultEnvironmentalProperties()
we'd have something likeHTTPManagerRequest.applyDefaults(from:)
(or maybeHTTPManagerEnvironment.applyDefaults(to:)
).Something I'm not sure about is how to handle multiple domains that should have the same properties, because keeping the properties in sync between environments when mutating them is annoying. We could give
HTTPManagerEnvironment
a whole array of domains instead of a single one. Another option is to have an option to "apply to subdomains" so I can just set up an environment for the root, though this approach is problematic if I want the default base URL to be a subdomain.The text was updated successfully, but these errors were encountered: