I have an API which returns a list of articles. An article can have three status: Approved, Pending and Rejected. Now the front-end needs to hit the API in following scenarios:Get all the articles irrespective of the status.Get all articles added by an user.Get all articles added by an user which are pending/rejected.Get all articles which are pending.There are two buttons on the front-end: one for fetching all pending articles so that they can be approved(only available for admin users). Another for fetching all rejected and pending articles for the logged in user so that he can see his pending/rejected articles. These two buttons are available on the list page of articles i.e. API has already been hit to fetch all articles and buttons are more like filters now.Is it good to return following dict along with list of all articles on the first API call :{  admin_approval: [Pending],  self_view: [Pending, Rejected]}So that front-end can know which all status need to be passed in the query params for filtering on subsequent button hits? Or should the logic which decides which filters to apply be hard-coded on front-end?P.S Using Django for back-end and Angular for front-end.
Hardcoding on frontend
rest;api;django;front end;backend
The answer to this depends how much you want the UI to cope with future requirement changes, such as additional buttons for different kinds of filterings. For trivial apps, most people will hard-code filtering object into each button. However, if you want the system to be extensible, and you have a total control over the REST API, I'll suggest that you add another API endpoint that return all supported filtering modes. So, basically, you'll haveREST endpoint for fetching all articles: like http://your-machine/api/v1/articlesREST endpoint for fetching all supported filtering modes: like http://your-machine/api/v1/filtersThe second endpoint will then return an array that has enough information for you to render buttons, and know which filters to apply when any of the button is clicked:[    {        name: wait_for_approval,        buttonText: Await Approval,        filtersBy: [ ... ]    },    {        name: self_pending_rejected,        buttonText: Pending or Rejected,        filtersBy: [ ... ]    },    ...]With this approach, it's future-proof as your endpoint can return a bigger array when requirement changes. clean as it also prevents you from polluting the first REST endpoint.flexible: if you have users with different roles, the REST endpoint simply needs to check credentials and return different arrays depending on which user makes a request.