For people who will use an API, is it easier to see:
This sounds like an assumption. Who are these "people" exactly? And how do you know what they will find easy? Were "the people" asked this question or was the assumption made without asking?
The standard is to use nouns in URI eg:
/user/ POST (Create a user)
/user/ GET (Get list of users)
You have a mistake here, should be
POST /users not
What are the consequences
Suggested approach is not idiomatic to web apis, it looks more like a C library than a web api. You can think of it, as of a person who is speaking a foreign language that (s)he didn't master very well yet and is borrowing grammar from his native language to express ideas. You can understand but it doesn't sound right and there probably will be expression issues if you need to discuss more complicated topics.
It's possible to have basic conversations without mastering language in details and is also possible to build simple functional web apis without mastering http design principles. Consequences will start showing up if you want to scale the api and will want to make use of existing http infrastructure which usually come in form of gateways, proxies, and client-side libraries. Things will be possible just everything will be harder.
In the end consequence is that every subsequent player that will need to deal with this api will need to deal with it sounding somewhat foreign. And there are many different players:
- end user (potentially your frontend developer, or 3rd party developers if you are building SAS)
- load balancers
- caching proxies
- api gateways
One affected area will be caching. HTTP is designed in a way that allows very effective caching layer to sit between client and your application without having any knowledge of your application logic. Cache layer will use resource url as a key:
Caching layer could be configured to invalidate the cache if write requests (POST/PATCH/PUT) are detected to that path.
Another affected are will be access control. Just like with caching if you will ever want to make use of existing web infrastructure to manage access control to your API (as opposed to implementing it inside your application's code) then following http best practices will make this possible.
You could configure a gateway, to allow unauthorized read requests to
/users/<x>, but block all unauthorized write requests. A token containing scope
users/1 and permission level
owner could instruct a middle-layer gateway to allow all write requests to
/users/1. An administrator's token that has scope
users and permission level
owner could allow write requests to any user.
Maybe you want to make use of off-the-shelf application that handles certain feature for example commenting instead of developing your own. You'll might then need multiple applications running under a common url umbrella. This can be handled with gateway and routing. If off-the-shelf application that handles comments follows good practices good chance is that you only will need to add single route
/comments and point it to that application.
/comments/<X> - app1
/users/<X> -- app2
if you used api suggested by your developer then chances are routing might need to be a lot more complex at some point.