Reputation: 897
I am working on api, using Laravel 5.6, for an application where I have been asked to come out with one route for all operations which could be controlled by the parameters sent. Doing it this way, is supposed to make the front-end developers' work easier where he / she does not have to worry about the different routes to be called, because one route does it all.
So there will be one controller with all the relevant functions in one method. The different operations on various tables should be differentiated on the basis of the parameters given and nothing else.
So I just wanted to know is it advisable to go ahead with this approach because I have never worked on this kind of concept.
Upvotes: 1
Views: 274
Reputation: 5963
As mentioned before, all of this would greatly depend on the data model, which is not clear from your question.
So the main question would be, what kind of data would the api provide?
But without knowing that, the proposed solution does not sound like a good approach to me.
The cons I would go with are:
It looks like the backend is fixing the lack of structure in the frontend.
Usually different frontend components would rely on different API endpoints. Mixing this will lead to difficult to maintain code on all fronts.
Frontend should worry about what they call.
I don't see the logic in that the frontend does know which parameters they want to send, but they don't want to know where to send it?
You are adding unwanted and unnecessary complexity to the api.
Think about how you would handle input validation, and how you would return this to the frontend.
For what it's worth;
I usually start of with a flat REST api, directly on the database models to allow simple CRUD and list with simple filter/sort/paging operations.
For Laravel that would mean using resource controllers on top of your entity, which would expose the CRUD endpoints for that entity.
This would expose a simple interface in which clients can fetch/create/update a single entity.
On top of that, and if needed, I will create additional API endpoints if a specific frontend/usage would require so, and on top of that it would have to make sense to move that functionality to the api/backend.
Upvotes: 1