page
and page_size
returned in common wrapper object, if I run /me/associated request. Why is it so? I am asking this because we have already sent these parameters as request. So getting the same parameters as response have no use.
1 Answer
First, page
and page_size
are NOT returned by default. You have to specify a custom filter to get those.
If you don't want those properties, don't use a filter that requests them! :)
Second, there is a very good reason to have those properties in real-life scenarios:
Remember that API operations are asynchronous. This means that your app can't be sure of when it will get a response and responses may be out of order.
For example, you could request:
questions?page=1, questions?page=2, questions?page=3
But get back:
questions?page=1, questions?page=3, questions?page=2Many practical apps use several different kinds of API calls to perform their mission. These may use different page sizes for various reasons. (1, 30, 100, and 999 are all used in one of my apps, for example.)
Trying to hard-code or assume a fixed page-size in such an app will result in bugs and maintainability issues. It's far more elegant to have each call use the most appropriate page-size for its situation and have the API preserve that context.
Then you can use one common routine to do the initial processing of all API responses without having to try and track context in some kind of kludgey global structure.
-
Yes, I know that
page
andpage_size
are not returned by default. 2) & 3) This would apply when we are sending request. Is there some use when the response is returned? Also, in calls like /questions/add,page
andpage_size
doesn't make sense. What are your views?– amit jhaCommented Feb 25, 2016 at 10:17 -
Yes, pagesize can be useful in the response and, yes, it's not particularly helpful for things like
/questions/add
. I don't want to get into a pointless discussion on this. If thepage_size
return is useful to you, use it. If it's not useful to you, then don't use it and move on. Commented Feb 25, 2016 at 16:41