EVE Technology Lab

AWESOMEEEEEEEE.....

and now add an indicator on what I've found in the "CharacterID.xml.aspx" API... like don't do characterID when the ID belongs to a corporation...

just my 12.5 cents

Very nice -- thanks for your work. That should simplify quite a few things of mine, as well.

Unless you run into an issue where caching the results for what's essentially the same information twice taking up too many resources (note: I have no idea how the eve api's caching layer works! :V ) I don't see a real downside to having a new endpoint for it. Heck, didn't that happen for the killmails api endpoint at some point? I can't remember. As long as you don't remove the old endpoint, it probably won't change anything for previously existing code, and anyone who wants to use the new information was gonna have to touch their application anyways.

Since someone else asked and others might wonder, here is the URL I used to produce the result seen in the above screenshot: eve/OwnerID.xml.aspx?names=wtfbbq,Regner,Federal%20Marines,Gallente%20Federation,something%20invalid

don't hate testing

testing is your friend

I am writing a massive test suite for an api endpoint at work right now

kill me

This would be duplicating what the Locations API already does.

Is this live now? Or Soon(TM)?

FoxFour for president. I know a lot of people who will be extremely happy about this.

This.

The following is the primary inconsistency that is turning my own code into spaghetti:

• APIKeyInfo returns almost everything I need except Alliance information.
• CharacterInfo is better, but is missing character gender, ancestry, and publicly visible titles and roles, and is inconsistent (alliance vs. allianceName from the other calls) thus requiring edge case code. Titles and roles are public "get info" items in-game…
• CharacterSheet is even better, but some of our members may be reluctant to give away private information to our Auth service and is missing security status.

This makes progressive enhancement of the imported data quite difficult to implement, as with a zero-mask key (which is perfectly acceptable to verify control over a character) there is no alliance information. For auth services the titles and roles are important, and requiring a more expansive key from people with titles is not unreasonable, but the API as it stands now is killing me.

Adding the missing alliance information to the APIKeyInfo call, as I notice some screenshots in prior replies indicating, is a great step. Adding the missing public "get info" information would be even better.

I'm glad to see attention being paid to the API. Ensuring compatibility while making additions should be fairly reasonable.

My blue-sky hope is for the serialization format to be selectable. JSON FTW.

Edited to add: camel case keys (tags/attributes) are used everywhere… except CharacterInfo, which returns 'bloodline' instead of 'bloodLine'. The more I use the API the more I want to flip my desk.