dkurok

api/v3/lego/parts/{part_num}/colors/ should not use paging

Recommended Posts

Hello,

I think the GET /api/v3/lego/parts/{part_num}/colors/ API-function should not have paging. There are only 133 colors over all and I guess there is no part which is available in all colors.

Because the page-size itself cannot be set in the API and defaults to 100, this function should always return all colors the requested part is available in. This keeps away the overhead from the consumer to handle the rare case there are more than 100 colors available for a part (are there any?:unsure:) and in worst case (133 colors for a part) puts 1/3 more to the answer (instead of maybe handling an addtional call for page 2, which normally is more costly on both side (client and server)) - maximum 33 * ~200 bytes = ~7kB more instead of a asecond call.

Regards

Dietmar

Share this post


Link to post
Share on other sites
2 hours ago, dkurok said:

Hello,

I think the GET /api/v3/lego/parts/{part_num}/colors/ API-function should not have paging. There are only 133 colors over all and I guess there is no part which is available in all colors.

Because the page-size itself cannot be set in the API and defaults to 100, this function should always return all colors the requested part is available in. This keeps away the overhead from the consumer to handle the rare case there are more than 100 colors available for a part (are there any?:unsure:) and in worst case (133 colors for a part) puts 1/3 more to the answer (instead of maybe handling an addtional call for page 2, which normally is more costly on both side (client and server)) - maximum 33 * ~200 bytes = ~7kB more instead of a asecond call.

Regards

Dietmar

Any call that returns a list of items will be paginated by the framework I'm using, I don't want to change that. It shouldn't be too hard to write something generic that can detect a paginated response and retrieve all pages automatically.

Anyway, I actually changed the page size to 1000 the other day. I just forgot to update the documentation :) Be aware that the page size might decrease if it starts to cause performance problems, which I haven't fully solved since v3 went live.

Share this post


Link to post
Share on other sites
11 hours ago, Nathan said:

Any call that returns a list of items will be paginated by the framework I'm using, I don't want to change that. It shouldn't be too hard to write something generic that can detect a paginated response and retrieve all pages automatically.

Anyway, I actually changed the page size to 1000 the other day. I just forgot to update the documentation :) Be aware that the page size might decrease if it starts to cause performance problems, which I haven't fully solved since v3 went live.

Hello Nathan,

OK, I understand that. If it is a general framework behaviour, than this is clear...

Than I have to find a codepoint where to implement this paging in genereal.

The increase to 1000 helps in this special cae, but I see that xou can change it without any notofication (which makes sense for reacting quick on performance issues).

Thank you!

Share this post


Link to post
Share on other sites