Skip to content
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

Standardized Belgif problem type(s) for 409 Conflict #185

Closed
jpraet opened this issue May 21, 2024 · 4 comments
Closed

Standardized Belgif problem type(s) for 409 Conflict #185

jpraet opened this issue May 21, 2024 · 4 comments

Comments

@jpraet
Copy link
Contributor

jpraet commented May 21, 2024

The Belgif REST Guidelines make various references to HTTP 409 Conflict:

But no standardized Belgif problem type is currently provided. It should probably use the InputValidationProblem model, so additional details can be returned in the issues property.

@pvdbosch
Copy link
Contributor

We should probably change to http code 412 for optimistic locking scenarios; there's still open issue #37 for that.
For the others, we'll need to evaluate if single level of problem suffices for most of these use cases vs more complex InputValidationProblem model that allows bundling of multiple issues.

@jpraet
Copy link
Contributor Author

jpraet commented May 21, 2024

we'll need to evaluate if single level of problem suffices for most of these use cases vs more complex InputValidationProblem model that allows bundling of multiple issues.

Yes, that relates to the discussion on #114 (comment).

@pvdbosch
Copy link
Contributor

409 Conflict may also be used for PUT operation when a resource can't be updated bc of business rules; similar to the above DELETE scenario.
Do we need a generic problem type for such business-specific cases or should it be an API-specific problem type?

@pvdbosch
Copy link
Contributor

I've opened new issue #217 replacing this one, and also including cases like replacedSsin, mergedEnterprise, etcetera. It doesn't include optimistic locking, which is covered by #37.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants