Allow dashboard URL to be returned async-ly

[duglin]

See: https://github.com/openservicebrokerapi/servicebroker/pull/171

IMO the main reason behind async ops is because the server can't deal with it right away, which means in the worst case it might just stick the request into a queue and work on all aspects of it later. So that pretty much all data associated with the new resource might not be known at the time we return the response to the create request. This means that all data should be returned on the true async response and therefore dashboard URL should be in there too, not on the response to the original request.

[mcelep]

@duglin,there are use cases where the dashboard URL is very helpful for actions that require some manual user interaction. For example we have an sms service and before provisioning we want to verify the sender number so we have a small dashboard to enter verification code that is sent over an sms to the requested sender number. In this case the dashboard url, must be part of the initial provision response so that user can hit the dashboard right away.

So ideally we want to keep the dashboard URL in the provisioning response but add other means for service brokers to update dashboard URL later in the provisioning.

[duglin]

@mcelep agreed, I wasn't planning on dropping the current field, just allow it to be empty and allow for it to be sent along later, after provisioning

[avade]

My concern here is by adding the possibility of returning it in two places adds some ambiguity for the platform.

Does the async response supersede the first response? If yes, what does this mean for users of that service instance?

Overall I agree with the proposal and in the spec, we should ensure that it is clear what the expected behaviour from the platform is.

[mattmcneeney]

The dashboard_url can now be fetched via the Fetching a Service Instance endpoint, so closing this!