-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Be clear about the state of resources after a failure #541
Conversation
Hey duglin! Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you and the commit authors have already signed the CLA. |
@duglin Does this text make sense given that we use I agree with this text for all other 4xx and 5xx codes. |
I think a 410 is still ok with this text because its still "Gone" after the broker responded with a "410 Gone". Its still semantically in the same state. Right? |
Updates the text based on yesterday's meeting |
I'd like to keep the first MUST but if people are afraid that we can't due to it technically being a breaking spec change, then we can drop it down to a SHOULD. But since 4xx's are means to be error for "bad input" I figured brokers should catch these before any real processing on the resource happened. Signed-off-by: Doug Davis <dug@us.ibm.com>
Inconsistency introduced by: openservicebrokerapi#541 Fixes openservicebrokerapi#563 Signed-off-by: Doug Davis <dug@us.ibm.com>
I'd like to keep the first MUST but if people are afraid that we can't
due to it technically being a breaking spec change, then we can drop it
down to a SHOULD. But since 4xx's are means to be error for "bad input"
I figured brokers should catch these before any real processing on the
resource happened.
Signed-off-by: Doug Davis dug@us.ibm.com