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:

  1. Get all the articles irrespective of the status.
  2. Get all articles added by an user.
  3. Get all articles added by an user which are pending/rejected.
  4. 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.

  • Does the front-end know if the current user is an admin or is that information only available in the back-end? Jun 8, 2017 at 8:53
  • front-end knows user is an admin Jun 8, 2017 at 9:41

2 Answers 2


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 have

  • REST endpoint for fetching all articles: like http://your-machine/api/v1/articles

  • REST endpoint for fetching all supported filtering modes: like http://your-machine/api/v1/filters

The 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.

Its a better solution to pass the expected values rather than hard code it in front end. In future, you may have another possible state/status. It will be far easier for the backend to pass this new value and the UI to handle it dynamically by displaying another button or a drop down.

  • but that is what the article list API is not supposed to do. It has only one purpose i.e to return list of articles based on filters passed as query params. Why clutter it with sending extra data that is pretty irrelevant considering the purpose of the API. Jun 8, 2017 at 7:54
  • Agreed, you can pass it in the same call (not preferred but efficient) or provide a separate method to get the list of states.
    – Diceyus
    Jun 16, 2017 at 13:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.