There does not apear to be a dedicated thread for general Comunity Platform API feedback, so I thought I would start one. Only Grotako’s thread is more general in nature http://us.battle.net/wow/en/forum/topic/2516991705 , but that is limited to the Character, Guild and Arena API’s.
Now for some feedback. Let’s take a look at the URL buildup for the different API’s.
Realm Status API
http://{region}.battle.net/api/wow/realm/status?realm={realm_name}
| |_________________| |_____| |__________| |________________|
| | | | |
scheme[1] domain[2] api[3] api-path[4] parameter[5]
Character API
http://{region}.battle.net/api/wow/character/{realm}/{name}?fields={CSV}
| |_________________| |_____| |______________________| |__________|
| | | | |
scheme[1] domain[2] api[3] api-path[4] parameter[5]
Guild API
http://{region}.battle.net/api/wow/guild/{realm}/{name}?fields={CSV}
| |_________________| |_____| |__________________| |__________|
| | | | |
scheme[1] domain[2] api[3] api-path[4] parameter[5]
Arena API
http://{region}.battle.net/api/wow/character/{realm}/{size}/{name}?fields={CSV}
| |_________________| |_____| |_____________________________| |__________|
| | | | |
scheme[1] domain[2] api[3] api-path[4] parameter[5]
As we can see part [1] [2] and [3] of the URL buildup are concise. Part [3] and [4] make up the path of the URL, with part [4] having a different makeup depending on the API being called. Part [5] consists of a query.
Consistancy
The API’s mentioned here can be split into two groups when looking at URL buildup; the Realm Status API and the other API’s. The Realm Status API does not contain any variable information in it’s path [4]. The other API’s do contain variables in their paths. What at first seems like an inconsistency is actually a well thought out design. The goal here was to have the base URL (part [1] through [4]) contain the bare minimum of information necessary for each individual API to return a default payload. Additional parameters [5] can be added to each of the API URL’s to narrow down or to expand upon the information returned by the targeted API.
What I do find confusing however is the difference in the query-string [5] buildup between the Realm Status API and the other API’s. The Realm Status API has a traditional build up where the realm parameter can be repeated thus:
?realm={realm_name}&realm={realm_name}&realm={realm_name}
Whereas the Other API’s consist of one parameter (fields) which can hold comma separated values, like so:
?fields={CSV}
Why not also have the Realm Status API reflect parameter usage in the same manner and have realms be a single parameter with comma separated values?
?realms={CSV}
Validation
The API payload is a JSON format and since there is not yet a JSON schema language approved by a standards body, validating the payload is not a given. The old armory had an XML payload and no schema attached to it (at least not to the outside world), but the hierarchy and makeup of the payload did change over time. Keeping up with those changes without schema validation was a challenge.
To not have history repeat itself I would like to suggest the use of Orderly ( http://orderly-json.org/ ) or a similar library to compile JSONSchema’s. (I really love the idea of schema’s that are defined in the same language that they are validating, just like XML) Those schema’s can then be made public through the API URL like so:
http://{region}.battle.net/api/wow/realm/status/schema
http://{region}.battle.net/api/wow/character/schema
http://{region}.battle.net/api/wow/guild/schema
http://{region}.battle.net/api/wow/character/schema
In keeping with the design of the current API’s, the above mentioned URL’s would return the latest version of a schema. Older schema’s can be returned with an aditional parameter:
?version={version}
This alone would help tremendous amounts towards building fault-tolerant systems that consume the Comunity Platform API’s. The addition of the schema version in the payload would be an added bonus, but certainly not a necessity.
{
"schema":"v1.2",
"realms":[
{
"type":"pvp",
"queue":false,
"status":true,
"population":"medium",
"name":"Dunemaul",
"slug":"dunemaul"
}
]
}
EDIT: Many changes.
You can: "http://us.battle.net/api/wow/realm/status?realms=Medivh,Lightbringer" |
|
JSON validation is something that there doesn't seem to be a clear standard or best practice on, so I opted not do anything with it. I'd rather not have some sort of schema than pick one, have it not be what is used by most people and have to either change it or deal with whatever missing features or components it has. |
|
API versioning is something that has my interest and I know we should do. What will likely happen is we will implement API versioning once we introduce deprecated APIs. I like the idea of having the core/root API urls act as references to whatever is the latest and providing versioned APIs for specific backwards comparability. This is all based on a lot of what-ifs, but when we need to introduce versioning, it'll likely look something like this: Old APIs: /api/wow/realm/status *change that is made to deprecate it* New APIs /api/wow/realms /api/wow/v1/realm/status |
|
Not really. By the time we finish character profile APIs, guild profile APIs, updated feeds, auction house dumps, arena team feeds, pvp data APIs, static data APIs, internal and external application registration we cane take on the numerous "nice to have" features that this falls under. |
|
Technically speaking, the token "Medivh" is different than the token "Medivh " and the one with the space doesn't match a realm name. For the realm slugs, we do normalize spaces out of it, for the raw names we don't. It may seem a bit strange, but this is working as intended. I'll make note to state in the documentation that the onus is on the developer to trim strings appropriately. |
|
Yeah, totally a bug. We plan on removing the support for multiple 'realm' parameters in the near future. We'll also probably trim the comma separated values just for usability purposes too. |