fix: OperationNotSupported is 422, not 501 - #63
Merged
Conversation
TS 104-176 § 6.3.2 associates each API error type with one HTTP status code, and OperationNotSupported is 422. Four sites answered 501 with that type. Twenty-five others already used 422, so the house convention was right and these were strays. troeNotAvailable x2 broker started without TRoE / plugin lacks the op getEntitiesTemporal this q cannot be turned into SQL getEntities sort-by-distance needs a Point orderGeometry "Not Implemented" as a ProblemDetails title goes with them: that is 501's reason phrase, and beside a 422 it said something the status contradicted. All four now read "Operation Not Supported", except TRoE's two which keep the more specific "TRoE Not Available". troe_disabled_temporal_501.test is renamed - a status code in a test name ages badly, and this is the second status that test has asserted.⚠️ What this loses, and it is not nothing: 422 says "this operation cannot be performed", not "this build does not include that part of the API". Of the eleven registered error types exactly ONE describes the deployment rather than the request - NoMultiTenantSupport, at 501 - and it is reserved for a single capability. So a broker built without TRoE has no way to say so in a machine-readable field, and has to put it in the detail string where nothing can act on it. Filed as spec-doubts-2 #124, proposing a registered NotAvailableInThisDeployment at 501. That gap matters more than it looks: every feature a smaller build leaves out will hit it, and "the request was wrong" is the one answer a client must not be given when the truth is "ask a different deployment". 640/640 mongoc, 590/590 corDB.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TS 104-176 § 6.3.2 associates each API error type with one HTTP status code, and
OperationNotSupportedis 422. Four sites answered 501 with that type. Twenty-five others already used 422, so the house convention was right and these were strays.troeNotAvailable.c×2getEntitiesTemporal.cqcannot be turned into SQLgetEntities.corderGeometry"Not Implemented"as a title goes with them — that's 501's reason phrase, and beside a 422 it said something the status contradicted. All four now read"Operation Not Supported", except TRoE's two which keep the more specific"TRoE Not Available".troe_disabled_temporal_501.testis renamed to…_not_supported: a status code in a test name ages badly, and this is the second status that test has asserted.422 says "this operation cannot be performed", not "this build does not include that part of the API".
Of the eleven registered error types, exactly one describes the deployment rather than the request —
NoMultiTenantSupport, at 501 — and it's reserved for a single capability. So a broker built without TRoE has no way to say so in a machine-readable field; it has to put it in thedetailstring, where nothing can act on it.Filed as spec-doubts-2 #124, proposing a registered
NotAvailableInThisDeployment→ 501, withNoMultiTenantSupportas a special case of it.That gap matters more than it looks: every feature a smaller build leaves out will hit it, and "your request was wrong" is the one answer a client must not be given when the truth is "ask a different deployment".
Verification: 640/640 mongoc, 590/590 corDB.