Order of ids returned, v2/commerce/listings

#1 - Sept. 12, 2014, 11:48 p.m.

If anyone knows how the commerce API orders the data it returns, could they share?

I gave it five id’s not in numerical order. Specifically, they were ordered “1, 4, 5, 2, 3”

When I inspect the JSON returned, it gives me the values in “1, 2, 4, 5, 3” order. Still not sorted by ID, not in the order I gave them, and I can’t really find anything else that it might’ve sorted it by to achieve the order it gave them back in.

Ideas?

Pat Cavit

#15 - Sept. 15, 2014, 1:39 p.m.

StevenL.3761:
My best guess is that listings are (lazily) loaded in parallel, so the order would be undefined. For practical purposes, that means that the list goes from listings with few offers to listings with lots of offers.

No idea if that’s how it really works.

Yup, we make a bunch of async requests for the data and simply assemble it in the order it returns.

Now, as for object-vs-array:

Shoving results onto the end of an array as we get them back is easy and lets you do nice things like check the length of the array to see how many items you got back. It also means you can use useful array functionality like (JS examples) .some(), .every(), .reduce(), etc w/o first having to jump through a bunch of hoops.

Constant-time lookups of a specific data ID doesn’t feel like a worthwhile trade-off for an API that is generally intended to provide bulk data, and if you did want that you could ask the API for data for the specific ID you cared about.

I’m open to sorting by ID once we have all the data back if you’d find it useful, I don’t think it would help programmatic usage much but does make the data nicer to look at.

Pat Cavit

#17 - Sept. 18, 2014, 4:25 p.m.

StevenL.3761:
Is the public API written in .NET? You might be able to get better performance if you use Task.WhenAny() to process requests as soon as they complete. Waiting for all requests to complete before handling their response means wasted CPU time. Client applications will benefit as well if they support streaming JSON while it is still being created.

We don’t use .NET & for simplicity’s sake we don’t stream responses right now. We’re processing each individual request as soon as it completes but we’re not blocking on the responses or anything. It works like nodejs, conceptually.

Pat Cavit

#19 - Sept. 18, 2014, 5:22 p.m.

StevenL.3761:
Oooh I had no idea that nodejs works with IIS.

It’s not nodejs, it just works like it. We use ARR as a load-balancer and HTTPS endpoint which is why you’re thinking we use IIS.

Pat Cavit

#21 - Sept. 25, 2014, 3:48 p.m.

poke.3712:
Pat Cavit.9234:
Yup, we make a bunch of async requests for the data and simply assemble it in the order it returns.

Is that order consistent enough for paging though? I.e. when using the paging mechanism, can I be sure that I get every object at some point, or is it possible that some will be missed because the order for one page ended up being different than the other?

We start w/ the complete list of IDs for paging, so yes. Each individual page may not have a guaranteed order, but it does have a guaranteed set of IDs that will be returned.