NachoCheese.3084:

I used the APIs to write a twitter bot that tweets updated event information for some of the meta-events. When I fetch the current state of events using the events.json request, I get back a result like this:

{ "events": [
   {"world_id": 1008, "map_id": 873, "event_id": "659149D4-43EC-4DCB-A6BB-0B2D402B537B",
      "state": "Preparation" },
   // etc. etc. etc.
   ]
}

And the very first thing I do is transform this array into an easier-to-use object formatted like this:

{
   "659149D4-43EC-4DCB-A6BB-0B2D402B537B": {
      "world_id": 1008, "map_id": 873, "state": "Preparation"
   },
   // etc. etc. etc.
}

That way I can simply use the event_id to immediately find the details I need, rather than parse through the list to find an integer index, and use that for the rest of my process.

This may be more complicated specifically for the Events request, because without a world_id on the request, there will be many events with the same event_id and differing world_id. So this would either have to stay as it is, or world_id would have to be a required parameter. But for other calls, such as world_names, event_names, etc. there should be no problems returning in the format of “object_id”: { /* object details */ } for ease of use (and possibly quicker execution on our app’s side).

DarkSpirit.7046:

It sounds like you are deserializing the JSON data to a dictionary and attempting to use the event id guid as a key for a quick hashtable lookup?

As you already know, you can’t do that. The key has to be a combination of both the event id and the world id in order for it to be unique. Or you can have two levels of indexing via the world id and event id.

Cliff Spradlin.3512:

That way I can simply use the event_id to immediately find the details I need, rather than parse through the list to find an integer index, and use that for the rest of my process.

Yeah, I see why you’d want to do this. As you said, if we provide a complete event list it’s a problem to present the data in your proposed format since there are duplicate keys. I think that some people solve this problem by writing a search function, rather than by transforming the data.

For the ‘names’ APIs, we probably should have implemented them the way you said. I think I just expected people to basically load these into a table, rather than query the data directly.

Healix.5819:

You can store the data however you’d like when you originally read through the raw data. In this scenario, it doesn’t really matter what format it comes in since it’s basically the difference between {a:1,b:2} and {b:2,a:1}. In your case, you’d simply want to read each record into a map, rather than an array.

That said, most people are just going to use a simple solution to transform the data into an object and then go through it. In this case, then yes, you’re going through everything multiple times.

rodadams.5963:

For bits of data where there actually is a primary key, I don’t see a downside to return a map, since it’s about as easy to do a table scan across a map as an array.

Upside is it saves a bit of post processing on the client side.