rossheninger
commented
4 years ago LMK if my understanding here is accurate and I should never return a 200 w/ "state":"succeeded" for a deprovision
Open rossheninger opened 4 years ago
rossheninger
commented
4 years ago LMK if my understanding here is accurate and I should never return a 200 w/ "state":"succeeded" for a deprovision
mattmcneeney
commented
4 years ago I think you're right that this is a little ambiguous. Our expectation is that either approach is fine - a broker could return a HTTP 200 with succeded, or a 410 if it had immediately forgotten about the operation (potentially useful if a broker wanted to keep as little state as possible).
We can probably clarify this with a small text change, but can't say only one approach is now valid as that would be a breaking change.
What is the problem? The documentation is slightly unclear to someone unfamiliar with what the response should be from the polling last operation API after a deprovision request returns a 202. Myself and two other developers on my team had a debate as to whether or not we are supposed to return a 410 after a successful deprovision or a 200 with "state":"succeeded". It seemed like both options made sense but responses in the 400's make it seem like there is some sort of error.
After speaking with another developer who was more familiar, he told us that we should return 200's with "state":"in progress" until it finishes then return the 410. I think something should be changed in the docs to clearly state that you should never return a 200 with "state":"succeeded" for a deprovision. Currently it says 410's should be interpreted as a success on deprovision but it doesn't explicitly say not to use 200 w/ "state":"succeeded" which imo left it ambiguous.
Who does this affect? Service broker developers/platform authors.
Do you have any proposed solutions? Explicitly say not to return 200 w/ "state":"succeeded" in the response for deprovisions in the last operation API.
Additional context Add any other context or screenshots can go here.