open All Channels
seplocked EVE Information Portal
blankseplocked The API Dev Blog Trilogy - Volume Three
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 [2] 3

Author Topic

Lutz Major
Posted - 2010.10.05 11:50:00 - [31]
 

Edited by: Lutz Major on 05/10/2010 11:54:40
First: \o/

Second: would it be possible to change the parameter 'IDs' of /char/MailBodies.xml.aspx to 'messageIDs'? Would be more consistent.

Edit: the logonMinutes are a LIE!!!! They must be off by a factor of ..uhh ... 10 at least! Razz

Tonto Auri
Vhero' Multipurpose Corp
Posted - 2010.10.05 13:28:00 - [32]
 

Two suggestions and a question:
1. Consider returning a table describing required/optional access credentials for a requests that lack proper authentication/necessary parameters, additional to textual error message.
2. Clarify "/eve/CharacterInfo.xml.aspx" call to state that says that full/limited API keys should be ones matching chracterID to return the data.

Question: Does the addition of /account/AccountStatus.xml.aspx is a CCP's way to discourage the use of full API keys in web allications? (Killboards etc?)
What you plan to do to wear off the consequences?

Zhou Wuwang
Federal Laboratories
Posted - 2010.10.05 13:56:00 - [33]
 

Edited by: Zhou Wuwang on 05/10/2010 14:00:36
Originally by: Bluedagger
And if it is truly illegal to sell CCP property without a license, then tell Apple to remove this joke of an app already. If we can't have Capsuleer, then we can't have anything at all. http://itunes.apple.com/us/app/station-trader/id352212125?mt=8 Especially when they are making MONEY off of it.


The value of this app notwithstanding, it appears the author made sure not to use CCP IP. Notice the lack (based on the screens) of any Eve-Online images. I also don't see Eve-Online's trademarks anywhere. At a glance, it does not appear to be a copyright violation.

The issue with Capsuleer seemed to be capitalization. I think many people have good ideas, but those same people are going to be hard pressed to find someone to finance their development up front. Capsuleer's business model wasn't self sufficient.

Chruker
Posted - 2010.10.05 15:14:00 - [34]
 

Originally by: Zhou Wuwang
Quote:

Call Name: /account/AccountStatus.xml.aspx
Call Description: Returns basic account information including when the subscription lapses, total play time in minutes, total times logged on and date of account creation. In the case of game time code accounts it will also look for available offers of time codes.
Required Input: userID, full apiKey, and characterID.
Cache Timer: 15 Minutes



Sorry if this is nit picky, but why the characterID as an input?

Account is defined by a userID. Isn't it more like /account/Characters.xml.aspx?




I was wondering about this too, however it seems that the function call doesnt complain when I just give it userID and full api key. So this could just be a copy-paste error.

CCP Prism X


Gallente
C C P
C C P Alliance
Posted - 2010.10.05 15:48:00 - [35]
 

Some quick answers to raised questions:

OwlManAtt, BeanBagKing, Vesseper
There is room for so much more in the API. There's just a whole lot more tech debt to deal with as well. I had hopes to get the blueprint page in before Incursion.. but Murphy. I'd rather not promise anything right now but rest assured that there is a huge list of things that we want to get in. I don't really want to mention anything specifically because people get mad at me when I don't deliver stuff even if I make it abundantly clear I never promised to deliver anything. Embarassed

Wollari
The reason the cache seems to work between multiple API keys is because the userID is actually used for the cachekey rather than the proper entityID. This results in cache not being used at all for some calls. As "cache" for many of those is defined as "NO YOU! YOU GET NO RESPONSE!" this makes you happy and my DB sad.

As to the DDoS: The api employs a sadistic locking schema that will protect the DB and thus EVE Online itself. It is however horrendously sadistic and reduces the quality of service by quite a lot. It's a fairly substantial drop in the ocean of tech debt.

Zhou Wuwang
Yes, the account status obviously doesn't need a characterID for any sensible reason. That was a copy/paste mistake on my behalf that the proof-readers had no way of noticing on account of them lacking domain knowledge. Dev Blog has been amended.

You can also BR the lack of DOB in the characterInfo as it's derivable from the employment history in show info. It will be a good way of testing the API BRing pipe-line for me. Very Happy

DmitryEKT
You can always just go to:
http://apitest.eveonline.com/account/AccountStatus.xml.aspx?userID=<INSERTUSERIDHERE>&apiKey=<INSERTFULLLEVELAPIKEYHERE> and it should show you an XML with the information. When it's out on TQ removing the test from the URL should be enough.

As to questions regarding EVE Capsuleer: That's completely out of the scope of my work. I refrain from commenting on stuff I don't know anything about.

DmitryEKT
Clandestine.
Posted - 2010.10.05 16:44:00 - [36]
 

thanks for that, it worked, slightly shocked by the numbers, but i was expecting to be :)

now, on a related note, is there any way to "uncreate" an api key - creating a new one wipes the old one, but if i didn't want to have one active at all, there doesn't seem to be a way to do that?
yes, i know it's not something you can guess because of how long it is, but still, would be nice for those of us who are overly paranoid...

Usul Atreides
Posted - 2010.10.05 17:39:00 - [37]
 

Dune! <3

Also, awesome. Very Happy

Bai Guang
Caldari
Perkone
Posted - 2010.10.05 19:20:00 - [38]
 

Something else that would be nice to see on the CharInfo page would the the corp history and not just the current corp that char is in. This could also encurage people to use the API, vice "spider" eve-gate for that info.

Catari Taga
Centre Of Attention
Middle of Nowhere
Posted - 2010.10.05 20:22:00 - [39]
 

Edited by: Catari Taga on 07/10/2010 10:18:39
CharacterInfo.xml.aspx returns <alliancenDate>. Unsure what it is supposed to be but currently it is equal to <corporationDate>, not any alliance related dates.

edit: wow, bug report on this got accepted without discussion - what did you do to the bughunters?!

Cail Fortestan
Body Count Inc.
Mercenary Coalition
Posted - 2010.10.05 21:40:00 - [40]
 

Edited by: Cail Fortestan on 05/10/2010 21:42:57
Edited by: Cail Fortestan on 05/10/2010 21:42:35
I haven't managed to get the AccountStatus call to work yet, I just get the "There was an error processing your request. Please try again." html message. Is it enabled yet ?

My "Data Warehouse" downloads most of the API for loads of chars, this is the only call I can't get to work.

Just changing AccountStatus to Characters in the URL (with the same keys, etc.) works fine to retrieve the Character list.

Edit: Ah, looks like it is only on the test server atm, download from there works OK.

Catari Taga
Centre Of Attention
Middle of Nowhere
Posted - 2010.10.05 21:57:00 - [41]
 

Originally by: Cail Fortestan
Edit: Ah, looks like it is only on the test server atm, download from there works OK.

The entire blog (as well as the last one) is about upcoming changes to the API (Tyrannis 1.2).

Zhou Wuwang
Federal Laboratories
Posted - 2010.10.06 02:05:00 - [42]
 

Originally by: CCP Prism X
You can also BR the lack of DOB in the characterInfo as it's derivable from the employment history in show info. It will be a good way of testing the API BRing pipe-line for me. Very Happy


Done. BR 101589. Cheers.

Tiberius Romanus
Posted - 2010.10.06 02:52:00 - [43]
 

What's the maximum size of a message "body" in terms of characters?

I guess messageID's are bigint unsigned (64-bit integers), but are messageID's permanent (unique and persistent) or are the id's eventually reset and reused? What are the conditions for reset? Increment turnover? Time? etc.






Epitrope
The Citadel Manufacturing and Trade Corporation
Posted - 2010.10.06 08:49:00 - [44]
 

Thank you, Prism X and Stillman! These are fantastic changes, particularly the account status addition. It's wonderful to see progress on the API.

There is one concern that I have, but I believe it to be easily solved: will we be able to access the API methods (both old and new) via secure https instead of insecure http? The rise of private information available to the full API key makes me uncomfortable with sending and receiving so much in cleartext. Presumably setting it up is more difficult than I imagine, or else it would have been done years ago, so if I may ask, what challenges are in the way of adding https access to the API?

Squizz Caphinator
Woopatang
Posted - 2010.10.06 18:32:00 - [45]
 

Edited by: Squizz Caphinator on 06/10/2010 18:33:46
CCP guys, I'm bummed you skipped over my question... Don't make me drink all your beer!

Would the API team consider adding AllianceName and AllianceID to the Character Sheet?

edit: rogue quote

CCP Prism X


Gallente
C C P
C C P Alliance
Posted - 2010.10.06 18:47:00 - [46]
 

Edited by: CCP Prism X on 06/10/2010 18:49:14
Originally by: Squizz Caphinator
CCP guys, I'm bummed you skipped over my question... Don't make me drink all your beer!

Would the API team consider adding AllianceName and AllianceID to the Character Sheet?

edit: rogue quote


I am bummed that I made you bummed. Neutral
In all fairness it is both silly that the alliance info is not on the Character Sheet as well as increasing API chatter by forcing people to query corporation information for the alliance info. Sadly I'm still just getting into this whole API groove and only found out yesterday (iirc) that it wasn't included. Apparently I just assumed it was there (even having read over that exact code way too many times) as it makes no sense to not have it there.

That being said: I'm not at work so there might be sound technical reasons for not including it (doubt it though). But if it's just an oversight I'll try to remember to defect it on myself. I'd ask you to BR it but this is just so old that it has to be considered feature creeping rather than a defective implementation.

Less bummed? Wink

Edit: changing adjectives to more PC words.. Embarassed

Zhou Wuwang
Federal Laboratories
Posted - 2010.10.06 18:58:00 - [47]
 

Edited by: Zhou Wuwang on 06/10/2010 19:02:14
Regarding "/char/MailBodies.xml.aspx" --

Please consider placing the text of the "body" element inside a CDATA block. As I'm sure you know, CDATA is used about text data that should not be parsed by the XML parser. I note that the body text contains XHTML (line breaks for instance) and some eve-online specific tags. Obviously those tags inside a CDATA section would be ignored by XML parsers.

I've noted this before in the description fields of other API returns, but message bodies are quite longer fields and much more diverse.

CCP Prism X


Gallente
C C P
C C P Alliance
Posted - 2010.10.06 19:24:00 - [48]
 

Originally by: Zhou Wuwang
Edited by: Zhou Wuwang on 06/10/2010 19:02:14
Regarding "/char/MailBodies.xml.aspx" --

Please consider placing the text of the "body" element inside a CDATA block. As I'm sure you know, CDATA is used about text data that should not be parsed by the XML parser. I note that the body text contains XHTML (line breaks for instance) and some eve-online specific tags. Obviously those tags inside a CDATA section would be ignored by XML parsers.

I've noted this before in the description fields of other API returns, but message bodies are quite longer fields and much more diverse.



Most excellent point. Will probably break something sooner than later.

Squizz Caphinator
Woopatang
Posted - 2010.10.06 19:36:00 - [49]
 

Originally by: CCP Prism X
Edited by: CCP Prism X on 06/10/2010 18:49:14

Less bummed? Wink


Very! Thank you :) Every little bit helps.

Your beer is now safe from me, for now Twisted Evil

JuicyCakes
UK Corp
Posted - 2010.10.06 20:19:00 - [50]
 

Any chance CharacterInfo can return Employment info?

Thanks!

Imuran
Zentor Industries
Posted - 2010.10.08 11:01:00 - [51]
 

Originally by: CCP Stillman
Originally by: OwlManAtt
Could we _please_ get an API call to list blueprints with their ME/PE/copy flag? Just like the data you have for us on the S&I tab?

It's on the backlog, but that's not telling of when we'll have the time to implement it. We're currently working mostly on technical debt, like the caching solution.


That would be great if its implemented. TBH would settle for just the copy flag would make working out of NAV a lot simpler - have hundreds of BPCs for invention that through things into total confusion :D

Catari Taga
Centre Of Attention
Middle of Nowhere
Posted - 2010.10.09 11:11:00 - [52]
 

Edited by: Catari Taga on 09/10/2010 11:18:56
So on MailBodies it says: "Returns the bodies of headers that have already been fetched with the MailMessage call. [...] ... bodies cannot be accessed if you have not called for their headers recently.".

I haven't tested for the exact meaning of "recently" yet - I assume it's the cache interval of MailMessages but maybe you could just tell us - but would it be possible to add a meaningful error message to the return on a MailBodies call if MailMessages have not been queried recently enough? Currently it just gives a <missingMessageIDs> response which does not discriminate between truly missing messageIDs and those which just have not been queried recently enough. Even if your API servers are set up in a way that the headers are not cached after a while (i.e. if no longer "recently") the fact that no cached headers are found would be enough to trigger a meaningful <error> response about that fact.

(BR 101813)

Katrina Bekers
Gallente
Fighters Squadron
Posted - 2010.10.09 12:33:00 - [53]
 

Memcached? I hope you already had a shared cache system in place. Glad to know you have one now.

But...

...Why not going the extra mile and using the best tool for the job? I mean it.

CCP Prism X


Gallente
C C P
C C P Alliance
Posted - 2010.10.11 10:11:00 - [54]
 

Originally by: Catari Taga
Edited by: Catari Taga on 09/10/2010 11:18:56
So on MailBodies it says: "Returns the bodies of headers that have already been fetched with the MailMessage call. [...] ... bodies cannot be accessed if you have not called for their headers recently.".

I haven't tested for the exact meaning of "recently" yet - I assume it's the cache interval of MailMessages but maybe you could just tell us - but would it be possible to add a meaningful error message to the return on a MailBodies call if MailMessages have not been queried recently enough? Currently it just gives a <missingMessageIDs> response which does not discriminate between truly missing messageIDs and those which just have not been queried recently enough. Even if your API servers are set up in a way that the headers are not cached after a while (i.e. if no longer "recently") the fact that no cached headers are found would be enough to trigger a meaningful <error> response about that fact.

(BR 101813)


I cannot promise you anything about the cache lifetime. The access list is not set to expire but the cache server is a black box and might very well decide to expire something to make room for something else. There's nothing I can do about this as it's the nature of caching. Due to this it is highly likely that if you get messages returned, and then some missing messageIDs those missing messageIDs are stuff you have no access to, as the entire access list would expire at once, as long as you're only querying headers you should have access too.

Perhaps one day I'll have time to re-design the walker to efficiently be able to discrimante between the two but currently there is no way to do that without allowing constant user initiated DB dips which could eventually degrade the game playing experience. That's not an option and redesigning the walker for that fringe case is not worth dropping the other API work I want to get done. Wink

Catari Taga
Centre Of Attention
Middle of Nowhere
Posted - 2010.10.11 10:49:00 - [55]
 

Originally by: CCP Prism X
Originally by: Catari Taga
Edited by: Catari Taga on 09/10/2010 11:18:56
So on MailBodies it says: "Returns the bodies of headers that have already been fetched with the MailMessage call. [...] ... bodies cannot be accessed if you have not called for their headers recently.".

I haven't tested for the exact meaning of "recently" yet - I assume it's the cache interval of MailMessages but maybe you could just tell us - but would it be possible to add a meaningful error message to the return on a MailBodies call if MailMessages have not been queried recently enough? Currently it just gives a <missingMessageIDs> response which does not discriminate between truly missing messageIDs and those which just have not been queried recently enough. Even if your API servers are set up in a way that the headers are not cached after a while (i.e. if no longer "recently") the fact that no cached headers are found would be enough to trigger a meaningful <error> response about that fact.

(BR 101813)


I cannot promise you anything about the cache lifetime. The access list is not set to expire but the cache server is a black box and might very well decide to expire something to make room for something else. There's nothing I can do about this as it's the nature of caching. Due to this it is highly likely that if you get messages returned, and then some missing messageIDs those missing messageIDs are stuff you have no access to, as the entire access list would expire at once, as long as you're only querying headers you should have access too.

Perhaps one day I'll have time to re-design the walker to efficiently be able to discrimante between the two but currently there is no way to do that without allowing constant user initiated DB dips which could eventually degrade the game playing experience. That's not an option and redesigning the walker for that fringe case is not worth dropping the other API work I want to get done. Wink

No I didn't really care much about the differentiation at all, more about the cache expiry. I just wanted to know when I "have" to query MailMessages to give a user access to a message body. But I guess as long as "recently" is never shorter than the MailMessages cache interval the latter can always be polled before actually accessing a message, so I can live with that. I closed the BR.

Lost Hamster
Hamster Holding Corp
Posted - 2010.10.11 14:05:00 - [56]
 

Regarding account privacy / security.

The call: /char/MailBodies.xml.aspx
Is a bad idea. Every place where you used your full api key - could be some third party website - would be able to read your mails.

I strongly recommend to create a 3rd level API key, which contains the mailbody call, or completely remove the possibility to read the mails body.

What is if you have user names and passwords to external sites etc in the mails. I don't think that you would be happy if that could be read from anyone. (who have the full api key)

CCP Prism X


Gallente
C C P
C C P Alliance
Posted - 2010.10.11 14:26:00 - [57]
 

Originally by: Lost Hamster
Regarding account privacy / security.

The call: /char/MailBodies.xml.aspx
Is a bad idea. Every place where you used your full api key - could be some third party website - would be able to read your mails.

I strongly recommend to create a 3rd level API key, which contains the mailbody call, or completely remove the possibility to read the mails body.

What is if you have user names and passwords to external sites etc in the mails. I don't think that you would be happy if that could be read from anyone. (who have the full api key)



Reading mail bodies has been a highly requested feature for quite some time and it's removal is not really an option. That answer is not very helpful for your concerns but perhaps telling you that you can generate a new one, thus invalidating your old one, will sort you out. Wink
In the future we will dedicate work on attempting to make API keys less of an "All or nothing" deal but until then I urge everyone to regenerate your keys if you've given them to untrustworthy partners and be very wary of who you give your full key to.

Lost Hamster
Hamster Holding Corp
Posted - 2010.10.11 14:38:00 - [58]
 

Originally by: CCP Prism X

That answer is not very helpful for your concerns but perhaps telling you that you can generate a new one, thus invalidating your old one, will sort you out. Wink

I know, just probably many user does not know about the upcoming change. (they don't understand the technical terms, and probably missed the info)

Originally by: CCP Prism X

In the future we will dedicate work on attempting to make API keys less of an "All or nothing" deal but until then I urge everyone to regenerate your keys if you've given them to untrustworthy partners and be very wary of who you give your full key to.

Yep, it would be nice to have something in the middle.

Hel O'Ween
Men On A Mission
EVE Trade Consortium
Posted - 2010.10.11 16:46:00 - [59]
 

Originally by: Lost Hamster
Regarding account privacy / security.

The call: /char/MailBodies.xml.aspx
Is a bad idea. Every place where you used your full api key - could be some third party website - would be able to read your mails.

I strongly recommend to create a 3rd level API key, which contains the mailbody call, or completely remove the possibility to read the mails body.

What is if you have user names and passwords to external sites etc in the mails. I don't think that you would be happy if that could be read from anyone. (who have the full api key)



Exactly my thoughts.

Originally by: CCP Prism X

That answer is not very helpful for your concerns but perhaps telling you that you can generate a new one, thus invalidating your old one, will sort you out.



... which doesn't help with applications/services you use on a daily basis. KBs, for example. Auto-sync needs a Full API key ... and one of a director/CEO, who for sure has more interesting EVEmails than one og the lower grunts.

I appreciate each and every addition to the API arsenal. But the more you add, the more pressing is the need for granular right management with API keys.

Tonto Auri
Vhero' Multipurpose Corp
Posted - 2010.10.12 20:50:00 - [60]
 

Regarding API keys and access levels, I'd only ask to not dive into TS3 idiocy of "power levels".


Pages: 1 [2] 3

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only