From 4e1889019b09545ed37c964568a4e11bd747b751 Mon Sep 17 00:00:00 2001 From: Doug Davis Date: Mon, 9 Jul 2018 09:56:00 -0700 Subject: [PATCH] Be clear about the state of resources after a failure 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 --- spec.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/spec.md b/spec.md index b06caf0b..3dd6d7b0 100644 --- a/spec.md +++ b/spec.md @@ -294,6 +294,15 @@ use these error codes for the specified failure scenarios. | ConcurrencyError | The Service Broker does not support concurrent requests that mutate the same resource. | Clients MUST wait until pending requests have completed for the specified resources. | | RequiresApp | The request body is missing the `app_guid` field. | The `app_guid` MUST be included in the request body. | +Unless otherwise specified, an HTTP status code in the 4xx range MUST result in +the Service Broker's resources being semantically unchanged as a result of +the incoming request message. Additionally, an HTTP status code in the 5xx +range SHOULD result in the Service Broker's resources being semantically +unchanged as a result of the incoming request message. Note, the 5xx error +case is a "SHOULD" instead of a "MUST" because it might not be possible for +a Service Broker to guarantee that it can revert all possible effects of a +failed attempt at the requested operation. + ### Content Type All requests and responses defined in this specification with accompanying