0

I have users and posts. Users can make posts. I am creating an endpoint for the posts. Does this make sense?

Posts

/posts - POST, create post
/posts?{uID} - GET, get posts for user
/posts?{pID} - GET, get post by id
/posts/{pID} - PUT, update post by id

Is this good design? It seems that both GET requests are too similar. Should I create something more distinct like:

/posts/users?{uID} - GET, get posts for user

Cons of the first: Additional logic on the backend (if else logic, to see which parameter was passed) Cons of the second: Additional endpoint

GRS
  • 2,807
  • 4
  • 34
  • 72

1 Answers1

0

I think most of your API design looks good, however you should change it slightly to follow the resource orientation suggested by the common API design guidelines:

/posts - POST, create post 
/posts?userId={uID} - GET, get posts for user 
/posts/{pID} - GET, get post by id 
/posts/{pID} - PUT, update post by id

If you would like to have a nested structure rather than a query string to get all posts of a user, I would suggest to do the following instead of /posts/users?{uId}:

/users/{uId}/posts - GET, get posts for user
Philipp
  • 470
  • 2
  • 10