Defining the Application HREF should override the SDK's baseURL

stormpath / stormpath-framework-spec

Language-agnostic API specification for Stormpath Framework Integrations

12 stars 14 forks source link

Defining the Application HREF should override the SDK's baseURL #111

Open edjiang opened 8 years ago

edjiang commented 8 years ago

Talked about it in the Evangelism Monthly meeting today; Tom said this should already be behavior. I could not find this documented.

If an application has:

STORMPATH_APPLICATION_HREF=https://enterprise.stormpath.io/v1/XYZ

It should auto-set the Stormpath baseUrl to https://enterprise.stormpath.io/ for developer convenience.

nbarbettini commented 8 years ago

This is good, but we need to discuss where this logic will live. Probably at the integration level, but it may need low-level SDK support.

robertjd commented 8 years ago

I think that a framework integration should do this. It will achieve this by looking at the application.href option, and then passing a baseUrl option to the client constructor in the SDK. We should continue to maintain the REST clients, as created by the SDKs, as application-agnostic.

nbarbettini commented 8 years ago

+1 for this. I just had a customer run into the issue that this would solve: they changed application.href but not client.baseUrl and were confused why it didn't work.

This is a great idea!

cilim commented 7 years ago

Since the basePath is set to null by default, what should happen in scenarios where the basePath is set? Should the STORMPATH_APPLICATION_HREF take precedence over it?

For example if a user sets the STORMPATH_APPLICATION_HREF to https://enterprise.stormpath.io/v1/applications/XYZ and the basePath to api.stormpath.com or vice versa. Maybe throw a warning to the developer or raise an error?