[lhorie]

It feels like you're attacking a design without understanding the design principles behind it.

Looking at https://petstore3.swagger.io, the API is `/pet` (singular), because that's exactly what it represents: the type of a singular pet. This design choice has to do with orthogonality: for example, what is `POST /pets` supposed to do? Create a new list of pets? That makes no sense. If you want to argue that it should create a new pet, then that makes no sense either, because the endpoint is explicitly about a collection of pets. This distinction may seem like nitpicking, but consider an entity type of ambiguous plurality like `/group`. You want to be clear about whether an action on this endpoint applies to a `group` or to individual entities in the group and you want that semantic to be consistent with other endpoints.

On the same vein about orthogonality, `/user/{action}` is orthogonal to `/pet/{action}` in the sense that they both follow the same OOP-ish pattern. Calling an endpoint merely `/login` doesn't fit into that mold (e.g. Can a pet login? Why is `/login` floating without a noun, but `DELETE /user/{id}` isn't? etc)

The choices of PUT and POST have to do with what the HTTP spec says about idempotency. `PUT /pet` must be idempotent (i.e. upsert a pet), `POST /pet` is not idempotent (i.e. create a pet).

`POST /pet/{id}` is a bit of a seemingly counterintuitive one, but again it has to do with idempotency. It's actually a deliberate choice to indicate that there may be internal logic that isn't pure (for example, there may be a lastModified field).