BRAVA needs to collect all "calls"

[BrapiCoordinatorSelby]

Generated from comment in #16

If the server has a small default page size, not all "calls" will be collected for testing

[langeipk]

Overwrite the default page size of the calls resource should not be considered to solve this issue. I do not see a reason, why an endpoint should use small page sizes to separate the calls into buckets. paging make sence for calling resources that potential deliver high volume of data. But the call resource should not. This is even convenient for any application to get in one call all calls.

[patrick-koenig]

I am also of the opinion that a default pagination of 10, 20, ... per page or the pagination in general does not make sense for the /calls resource.

Wouldn't it be an idea to generally disable pagination for this entry point resource or at least have a default value of 1000 per page?

[BrapiCoordinatorSelby]

I might argue that as a client, it is BRAVA's responsibility to retrieve as much or as little data from a paginated call as it needs, instead of relying on whatever the server defaults are. There might be a server which has a low default page size for a reason which makes sense to their situation, for example a table on a UI.

However, in this case, I agree there is no clear reason for a default page size of 10 for the "/calls" call. And the BrAPI Documentation recommends a default page size of 1000 for most paginated resources.

I spoke with @lukasmueller and @nickmorales and they agreed to make their default page size bigger for the "/calls" call. Feel free to close this issue.

[nickmorales]

having a relatively low default page size seems to be pretty common (e.g. github uses 30, google cloud uses 50, etc). it would not surprise me if other brapi implementations run into this problem with brava if the pagesize is not explicitly set.

that being said we will change the response of the calls call to have a default pagesize of 1000 on our end.

[lukasmueller]

Just wondering again about the wisdom of using a default page size of 1000… I assumed that the default page size was what could potentially be shown to a user, and a thousand responses is a bit too high for anyone to digest… 50 or a maximally 100 would be better? 10 is indeed a bit small.

cheers Lukas

On May 24, 2018, at 10:29 AM, Nick Morales notifications@github.com wrote:

having a relatively low page size seems to be pretty common (e.g. github uses 30, google cloud uses 50, etc). it would not surprise me if other brapi implementations run into this problem with brava if the pagesize is not explicitly set.

that being said we will change the response of the calls call to have a default pagesize of 1000 on our end.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[langeipk]

Thanks all for the comments! I agree, that the endpoint implementors are the only authority to define page sizes. Thus, default page sizes per design is not a good idea. Because page sizes is strongly dependent on back-end query latency for the particular resource, expected data volume in the pages, network speed etc. Thus I suggest to close this issue, but create another in the API to remove pagination from the "/calls" resource

[BrapiCoordinatorSelby]

I don't believe this is a big enough issue to warrant changing the BrAPI spec. Pagination of the "/calls" call may not seem like a useful feature in this scenario, but keeping it is future proof and internally consistent with the rest of the spec. I consider the list of calls to be a potentially "large" (large for a user, not computationally large) array, with an unknown or inconsistent size, and it is expected to grow (slowly) over time.

Since Cassavabase is willing to change their default page size so that all the tests are run as expected on BRAVA, then I consider this issue closed.

@langeipk if you still feel strongly that the "/calls" call should not have pagination, feel free to open an issue and we can discuss it further with the community. I just don't want to turn this into a bigger discussion than it needs to be to solve the original problem.

[langeipk]

Thanks all for the comments! I agree, that the endpoint implementors are the only authority to define page sizes. Thus, default page sizes per design is not a good idea. Because page sizes is strongly dependent on back-end query latency for the particular resource, expected data volume in the pages, network speed etc. Thus I suggest to close this issue, but create another in the API to remove pagination from the "/calls" resource