|
Author |
Thread Statistics | Show CCP posts - 11 post(s) |
|
CCP Fallout
|
Posted - 2010.10.04 16:37:00 -
[1]
CCP Prism X's final entry into the API Dev Blog Trilogy outlines the new and improved hotness that will be the API. You may read all about it and how to test it using the API Test Service here.
Fallout Associate Community Manager CCP Hf, EVE Online Contact us |
|
|
CCP Prism X
Gallente C C P C C P Alliance
|
Posted - 2010.10.04 17:05:00 -
[2]
Quick and perceptive pilots may have noticed that the test api link didn't work. This has been amended.
But as a side-note we will regularly shut it down from the public to perform our own tests on it. In such cases I'll make sure to sticky something in the Tech Lab mentioning that. ~ Prism X EvE Database Developer Relocating your character to a cozy, secure container since 2006. Relocating your cozy, secure container to the EVE cemetery since 2008. |
|
|
CCP Stillman
|
Posted - 2010.10.04 18:15:00 -
[3]
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.
|
|
|
CCP Prism X
Gallente C C P C C P Alliance
|
Posted - 2010.10.05 15:48:00 -
[4]
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.
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.
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. ~ Prism X EvE Database Developer Relocating your character to a cozy, secure container since 2006. Relocating your cozy, secure container to the EVE cemetery since 2008. |
|
|
CCP Prism X
Gallente C C P C C P Alliance
|
Posted - 2010.10.06 18:47:00 -
[5]
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. 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?
Edit: changing adjectives to more PC words.. ~ Prism X EvE Database Developer Relocating your character to a cozy, secure container since 2006. Relocating your cozy, secure container to the EVE cemetery since 2008. |
|
|
CCP Prism X
Gallente C C P C C P Alliance
|
Posted - 2010.10.06 19:24:00 -
[6]
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.
~ CCP Prism X EVE Database Developer and Acting API Dude |
|
|
CCP Prism X
Gallente C C P C C P Alliance
|
Posted - 2010.10.11 10:11:00 -
[7]
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.
~ CCP Prism X EVE Database Developer and Acting API Dude |
|
|
CCP Prism X
Gallente C C P C C P Alliance
|
Posted - 2010.10.11 14:26:00 -
[8]
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. 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.
~ CCP Prism X EVE Database Developer and Acting API Dude |
|
|
CCP Prism X
Gallente C C P C C P Alliance
|
Posted - 2010.10.21 17:20:00 -
[9]
Originally by: Max Cetera And about API, any chance we could disable calls individually ? It seems technically doable at least (and not memory/processing heavy)
That is what people mean by granular/customizable keys and we do recognize the need for them. It's at the top of the Tech Debt list now that the caching has been ameliorated. Hopefully we will find time for it in the nearest possible future and will be able to present you with an awesome new API key schema with Incarna.
As always these are just my musings and are quite conditional to the whims of external pressures, so I cannot promise anything at this stage.
~ CCP Prism X EVE Database Developer and Acting API Dude |
|
|
CCP Prism X
Gallente C C P C C P Alliance
|
Posted - 2010.10.27 15:02:00 -
[10]
Originally by: Rampoulina I have been building an application using the new API call provided on http://apitest.eve-online.com, more precisely to fetch mail headers (http://apitest.eve-online.com/char/MailMessages.xml.aspx)
The call returns headers up until the 6th September (first time I tried the API) but no other mails after this, however my ingame mailbox does contain messages from after the 6th.
Is this normal since it is in testing phase? Should I post mails on Sisi in order to test my application?
Also, the "fromID" parameter works strangely: it will return messages older than the message specified by "fromID". This seems useless, what would be a lot more usefull is to provide messages more recent than "fromID"
PS: I have filled a bug report on this, id:102585.
The test API hooks up to SISI, not TQ. Unless someone is sending you mails on SISI no new mails get added so this is completely normal.
The fromID is supplied if you want to search back in time so I'm not sure why you think it is useless. As I see it you'd start off by requesting stuff without a fromID and thus get the most recent mail, then start paging back from the last ID given if you're interested in older mails. There's no going forward until the cache expires, at which point calling again with no fromID will repopulate with any new mails received while the "front page" was cached. Calling the parameter fromID felt very natural as you "then start paging back from the last ID given".
But I'm a developer, not a user. Feel free to elaborate on why this feels unnatural to you.
~ CCP Prism X EVE Database Developer and Acting API Dude |
|
|
|
CCP Prism X
Gallente C C P C C P Alliance
|
Posted - 2010.10.28 13:16:00 -
[11]
Originally by: Rampoulina Thanks for your answer, indeed I understand the usefullness of the fromID now. However, in other cases (most of mine anyway) what happens is this:
- User logs in for the first time on the application - Application fetchs the latest mails (no added parameters): 50 mails or less added - (What would be cool:) Every time the user refreshes her mails, a fetch with the latest messageID is made, so the API returns every message with a superior ID.
Otherwise to refresh the mails, we have to make the classic call, and are returned 50 mails, which is more heavy to download and to parse and useless since we already had them.
Ah right, now I understand where you are coming from with this!
You wont get any new emails unless the CachedUntil expires of course so you can safe yourself any parsing just by not refreshing the front page until you know the cache has expired. You can also just stop parsing the mails once you get to your latest maxID but that will not help you with avoiding the request of redundant data.
I will make a note of this. It's (most likely) preferable for everybody to have some optional bit to only fetch the refreshed data. It is however not going to happen for Tyrannis 1.2 as I do not like messing with approved release candidates. Tends to introduce more bugs than fix anything.
~ CCP Prism X EVE Database Developer and Acting API Dude |
|
|
|
|