What is the de-facto/conventional practice when enforcing business logic in a REST API and what HTTP Status Codes are used?
For example, lets say that I have a Player entity and a Team entity. A Team can have any number of players.
Let's say that my business logic (currently) prevents a Team from being deleted until all of the Players have been explicitly removed from the Team first.
If you execute a
DELETE http://api.foo.com/teams/15
and it still has Players associated with it, would you return an HTTP 409 (Conflict) or an HTTP 412 (Precondition Failed)? 412 seems more logical because I prefer to use 409 for indicating optimistic locking conditions.
Or perhaps - should that business logic condition even be enforced at all in a REST API? That is, if someone executes
DELETE http://api.foo.com/teams/15
shouldn't that just remove all Players and then delete the Team automatically? Is it more conventional to allow the DELETE to execute as the REST API can be perceived as a little 'lower level' or more 'raw' than UI interfaces?
Finally, what about a query param to in the Resource URI:
DELETE http://api.foo.com/teams/15?force=true
which indicates, "Yes, I know that this wouldn't be allowed with players still on the team, but do it anyway".
The idea here is that deleting a Team can be a heavyweight operation with significant repercussions and you only want to do it if the end-user is really sure they want to.
In other words, how much hand-holding do you do (employing 'are you sure?' error codes) or do you just execute it without any check? I'm not quite sure if this should be enforced only in the UI or in the REST API or both. How do most people solve this today?
The client tried to do something that for business reasons was not a valid request. Therefore, I would use 400. Use the ReasonPhrase/entity body if you want to communicate additional details.