In addition to the OP comment
Yes, that was my point I gave them, but they needed concrete reasons
why it will fail in the future
Nobody knows the future. If your model and requirements do not change
over the next 100 years, the solution purposed will be a successful one.
Whoever we all know that changes happen. Requirements changes, the business changes and (from my experience) these so generic and abstract collides with flexibility eventually.
For instance, back to your scenario, at some point, everything that does not fit into the query string will be forced to travel through the body and some GETS will turn into POST/ PUT and the grammar of your API will be a little bit convoluted and hard to read.
Will it be okay if we scale it all up in the future? (And I'm sure we
It's hard to predict how the approach will impact to the scalability. There're different ways to scale up and all of them depends on different needs and scenarios. So as I have read here many times start little and then scale based on real needs.
However, we can say that technically, the approach has some limitations like the one I have pointed out previously.
Like, add token authentication, user roles, mobile access and
more. Would like some insights.
This sort of features can be implemented (and the often are) using the headers of the request and response. The approach exposed might no have an impact.
In addition to @Michael answer.
To use some API RESTful principles will bring some advantages:
- API (syntactically) will be more intuitive
- It will be more "devs-friendly*. These days developers are used to this kind of syntaxis and design. So it makes easier to them to implement clients.
- The way to scale up is predictable (because its scalability has been proved many times by projects that applied'em)
- The possible drawbacks of this approach have been already detected and the community has offered several solutions to every one of them. So no need to improvise solutions which result nobody knows.
- This one is the one that nobody things (or does rarely). The approach could be the result of someone's "brilliant idea* who may be and only may be, will be there during all the API's lifetime and its maintenance will be possible with a low cost. But as I use to say Do things like you were not going to be there to maintain them. Anybody that may come after you should be able to understand the solution minimising the learning curve.
Finally back to the OP comment
but they needed concrete reasons why it will fail in the future
Would be good for you and any other involved into the development, to know "they" reasons to implement a single endpoint. Which are their arguments? The against and for. Then you will be in the position to reply with arguments that they might understand.