
Ereshgikal
Strange Energy The Bastion
48
|
Posted - 2015.11.29 15:49:44 -
[1] - Quote
Working through the returned data in /API/CallList (building a small api-lib for myself) I noticed that two calls are listed that return 404 from the server.
row accessMask="16777216" type="Character" name="CharacterInfo" groupID="3" description="Sensitive Character Information, exposes account balance and last known location on top of the other Character Information call."
row accessMask="8388608" type="Character" name="CharacterInfo" groupID="4" description="Character information, exposes skill points and current ship information on top of'Show Info'information."
Ok, technically /EVE/CharacterInfo returns information about the character, but the endpoint is not /Char/CharacterInfo. In addition you could also call /EVE/CharacterInfo with an empty access mask, so that is missing as well.
row accessMask="33554432" type="Character" name="AccountStatus" groupID="3" description="EVE player account status."
This one is also technically related to a character, but its endpoint is /Account/AccountStatus, not /Char/AccountStatus.
It is possible I have misinterpretted the purpose of /Api/CallList and that "type" is only referring to type of the keyID/vCode pair, not to the actual API-path itself.
I am tempted to necro my old post from last year about having the API to be self-documenting: https://forums.eveonline.com/default.aspx?g=posts&m=4817627
|

Ereshgikal
Strange Energy The Bastion
48
|
Posted - 2015.11.29 20:13:52 -
[3] - Quote
Desmont McCallock wrote:Ereshgikal wrote:It is possible I have misinterpretted the purpose of /Api/CallList and that "type" is only referring to type of the keyID/vCode pair, not to the actual API-path itself. Bingo!
I am glad to be wrong in this case.
However, it then becomes even more interesting to have /Api/CallList to provide the API path for each call explicitly (and all parameters the call would take, but that is second step in improvement).
Adding a new attribute, for example "apiPath="/eve/CharacterSheet.xml.aspx", to each call should be fairly easy and shouldn't break existing parsers. (If nothing else, it would keep stupids like me less confused.)  |