recently I come across an issue that I don't know which is a good (standard) way to handle it in REST Api.
The problem is very simple. We all know that in standard REST Api, we use Get request to get data and Post request to send data to server to create/update resources.
For that, if we want to get a list of all users in our application, we would use a GET request with url like this: HTTP GET /users
That's easy right. Let's get to our scenario. Our application allows users to create their own post and people can comment, like, or follow posts created by them or other users. On top of that, we have billions of existing users.
Now, let's say we have a post that has been interacted with thousands of users (popular post) and we want to return that list of users. For this to work, we would at least need to send to server the post Id to look up. Obviously, we do not want to return a list of thousands of users at one time. That would be too much for front end to handle. For that, we would introduce a pagination number and page size to limit the number of users returned. Therefore, on top of the post Id, we will need to send page number and page size as well.
Now, we will have two ways to construct our request:
GET request: /users?postId=123&pageNumber=1&pageSize=10
POST request /users with body request
{
"postId": 123,
"pageNumber": 1,
"pageSize": 10
}
GET seems to be a standard one because it is querying and returning data to front end, but again, the postId is exposed to public. POST, on the other hand, is a bit more safer since parameters do not store in browser
Which one is the more standard one and recommended in this case ?
Use Get.
What concerns you about the post id appearing in a URL?
If all relevant endpoints are secured, there's nothing a user can do with that id unless authenticated and authorized to perform an action on that post.
Besides, the body of a posted request can be viewed in the browser's dev tools so a post just obfuscates the data a little. It doesn't actually secure it.