In an HTTP application, I think about routing requests based not only on the path, but also based on the request body. For an example, think about the following two different body schemas for a PUT request against an /orders/{id} endpoint:

A

{
    adminPassword: String,
    status: String,
}

B

{
    clientSecret: String,
    deliveryAdress: Object,
}

The requests should be routed to a different controller.

Of course, the business logic could be expressed by differentiating the two requests by assigning each an individual path. But I think there is some semantic benefit in having exactly one path for all updates of a entity, in different ways.

The idea is inspired by how Erlang and Elixir allow multiple function clauses with pattern-matching.

If I understand it correctly, it would be not native and probably hard, maybe even impossible, to reflect this API structure in OpenAPI. That in itself is a strong argument against this idea.

What other arguments speak against this approach? Has this been tried before?