If that PR is adopted then we'll require brokers not to change the service upon failure for 400's, but we're still silent on 500's. Can/should we say anything at all about 500's?
IMO if we can't guarantee that the broker didn't change the service, and we can't guarantee that the client can GET the current status, then no one should ever update a service - ever! It seems to me that if a service can't make any guarantees then it shouldn't offer to upgrade the service since the client may be left with no other option but to delete it and start over. Even if the client can GET the status, being able to know that its in a bad state, while better than not knowing anything at all, still means that update() is a risky operation and I would question why anyone would ever do it if they could lose all of their data (aside from test envs).
mattmcneeney
commented
5 years ago
See: https://github.com/openservicebrokerapi/servicebroker/pull/354
If that PR is adopted then we'll require brokers not to change the service upon failure for 400's, but we're still silent on 500's. Can/should we say anything at all about 500's?
IMO if we can't guarantee that the broker didn't change the service, and we can't guarantee that the client can GET the current status, then no one should ever update a service - ever! It seems to me that if a service can't make any guarantees then it shouldn't offer to upgrade the service since the client may be left with no other option but to delete it and start over. Even if the client can GET the status, being able to know that its in a bad state, while better than not knowing anything at all, still means that update() is a risky operation and I would question why anyone would ever do it if they could lose all of their data (aside from test envs).