I was playing with the API by doing a parse of /highscore endpoint of all universes in all regions. And it called my attention, that to obtain all the existing universes in a specific region, a universe id must be provided. It actually makes no sense, at least for me.

We all know the structure of this SOAP API: "s + ${serverId}-${region}.ogame.gameforge.com/api/${endpoint}.xml"

So, if I want to get all the universes from one region, let say AR region, I must do a request to "s" + ${serverId}-ar.ogame.gameforge.com/api/universes.xml" which does not make sense, because it makes you know on behalf a serverId which in fact, it's what you are trying to find. So, would it not better that for this endpoint, to be something like "https://ar.ogame.gameforge.com/api/universes.xml" ?

I think this was done this way, to keep aligned with the rest of the endpoints, but from a logic perspective, it does not make sense.

Shall it be changed or would that endpoint provide more data on the future which is respective to each universe? Today, it returns a timestamp, the server id, which we already know and the most valuable part, the list of available regions in that region.

But from an app side, this actually sucks.
Let’s say you use s121 and one day this universe is merged with another one.
You are forced to do this request with the rest of the avaialabe universes you may or not have. Until one returns http 200 and then, you update your universe list.

On the other side, it’s true that this does not happen frequently, but still from a SOAP Service perspective, it’s ironic that you need a serverId to obtain the rest of them.

@Malakian
Sorry I did not continue the idea, I have been pretty busy these last weeks.

I already have an idea to rework the current API, but I do not think this will have priority for the devs.

Still, I will provide an API spect proposal using RAML and will let it in GitHub so anyone can share their feedback