Hello im about to create dasbord for my website..

Dashboard will have multiple subpages like users, posts, roles etc..

I was thinking i would use only one rest api endpoint for those resources like




and create enum for each of those which will be used later on to query data.

Is this good practice, or i should create rest api endpoint for each of those

  • 1
    3 dvs and 0 comments? What gives? A down vote should be thought of as a suggestion to OP to change their post. Suggesting this without a why or a how is confusing and helps no-one. This hurts the site more than unpolished question do. I don't understand why someone would sacrifice rep to do something that isn't even helpful.
    – Nate T
    Sep 22 at 3:32
  • @Nate, my exact frustration with this site. Should it not be made mandatory that every downvote should be accompanied by a comment. Invisible people downvoting a question without why is just ridiculously toxic if you ask me.
    – elfico
    Sep 23 at 19:59

Those links are more pages under the admin area of your website.

An api call would typically go to: /api/users, /api/projects, etc.

An HttpGet to /api/users would return all the users in application as a collection of DTOs; usually as JSON.

To return a specific user with id=4. HttpGet to /api/users/4.

There are lots of resources online; the above is a very basic example


If your API is follows the original REST specification then what URLs you use makes no difference. In fact it is better if they are unpredictable. That way people don't hard code them into clients. You should use a media type like Hypertext Application Language which will allow hypermedia traversal of your endpoints using rels. This decouples the client from the server and lets you change your URLs in future if you need to without breaking the client.

To save you pain let me just disclose that pretty much noone follows the original REST specification so while this is the best way to do it you won't find much help online if you go for proper REST.

  • Isn't designing predictable apis baked into the ReST protocol? One of the most important factors when designing an api is UX. APIs are not meant to be hard to figure out. Their sole purpose is to facilitate interfacing from other applications. They are meant to be coded into clients, though obviously not hard-coded.
    – Nate T
    Sep 22 at 3:41
  • @NateT, The ultimate example of an API that follows REST to a t is a website with server-side generated pages. Navigation is through links within those pages, not by knowing what to type in the address bar of your browser. Sep 22 at 6:03
  • What we commonly think of as “RESTful” isn’t really when you dig into it; very few implementations go as far as providing links to other resources, etc. It maybe needs a different name for the semi-standard “pattern” of api/{resource}/{uniqueRef}, using HttpVerbs and returning JSON? Sep 22 at 6:42

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