These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
Previous page123Next page
 

API Deployment: Odyssey 1.0.10 (Deployed to TQ 20130626)

First post
Author
CCP Prism X
C C P
C C P Alliance
#21 - 2013-06-26 14:49:29 UTC
Acidictadpole wrote:
Getting cached results instead of an error is an excellent new feature. Thankyou very much.

On a slightly different topic, will there come a time where a characters LP counts are accessible via API?


Suggestion stuff goes here. It's much more likely that I'll do it if the list is public rather than privately maintained (read: forgotten) by me. Lol
Laendra
Universalis Imperium
The Bastion
#22 - 2013-06-26 19:19:28 UTC  |  Edited by: Laendra
Nice stuff
ItsmeHcK1
Immortalis Inc.
Shadow Cartel
#23 - 2013-06-28 08:42:05 UTC
King of the north! Wait...

Seriously though, we love you. <3
Remind me to buy you a beer next fanfest.
Ydnari
Estrale Frontiers
#24 - 2013-06-28 13:27:06 UTC  |  Edited by: Ydnari
CCP Prism X wrote:

Fixes
- Missing owner typeIDs have been added to the following pages (this should remove the need to make up to three calls to know wether a given ID is a character, corp or an alliance):
-- char/ContactList.xml.aspx
-- char/MailMessages.xml.aspx
-- char/UpcomingCalendarEvents.xml.aspx
-- char/WalletJournal.xml.aspx
-- char/WalletTransactions.xml.aspx
-- corp/ContactList.xml.aspx
-- corp/WalletJournal.xml.aspx
-- corp/WalletTransactions.xml.aspx


This is good stuff, have been able to bypass some crufty code that tried to work out the type, or left it as "unknown".

I still have that branch of the code active though but with a warning that logs every time it's used; the only place it's showing up now is for Contracts.

Shouldn't Contracts -> assigneeID and acceptorID have corresponding typeID columns? First one can be alliance, corp or character, second can be corp or character. All the other fields are unambiguous.

--

Acidictadpole
Perkone
Caldari State
#25 - 2013-06-28 13:47:06 UTC
CCP Prism X wrote:
Acidictadpole wrote:
Getting cached results instead of an error is an excellent new feature. Thankyou very much.

On a slightly different topic, will there come a time where a characters LP counts are accessible via API?


Suggestion stuff goes here. It's much more likely that I'll do it if the list is public rather than privately maintained (read: forgotten) by me. Lol


Got it, thanks for the referral.
Cyerus
Eternal Strife
#26 - 2013-06-29 19:12:13 UTC
Just here to give PrismX a real manhug! Bear
Desmont McCallock
#27 - 2013-07-14 13:55:46 UTC
So I tried to switch to the new KillMails call today for EVEMon but I can't seem to get any entries from it for any character I tried. Anyone else experiencing the same or am I doing something wrong?
(And for those of you that will ask, yes I get a valid API xml result but it has no entries in it).
Cyerus
Eternal Strife
#28 - 2013-07-16 15:00:46 UTC  |  Edited by: Cyerus
Even though I was initially very happy with the update (read 2 posts up), one of the changes makes me very sad.

Up until the update we had a clear difference between the API errors and HTTP errors. API errors show what's wrong with the request you are doing, while HTTP errors generally meant something was "wrong" with the API servers. This made it possible to run different pieces of code by checking the HTTP errors, and if an HTTP 200 was returned (means request OK), you'd be able to check the replied XML for any API error codes and present the user with a detailed explanation of what was wrong.

Currently all I'll receive back in case of an API error (examples like invalid characterID or invalid API details or perhaps the API access has been disabled because of an upcoming patch) is the HTTP 403 error. In my case this error would make the script stop functioning, as I don't want to continue querying if the API servers are crumbling. True, this behaviour could be changed but what do I do instead?

Should I assume the API servers are temporarily disabled and stop querying, but continue in a few minutes?
Or should I disable the user and list a long list of stuff that could be wrong the API details he used?


In the end the use of the HTTP 403 header is correct; The API server can't give you the requested data as some (if not all) of your access keys are invalid / expired. But is that really the behaviour we'd want from the current API system? Instead, I'd like to present the users with a clear description of what went wrong (the old situation). Preferably with an HTTP 200 code as the request should always be accepted (exception in API downtime or patchday) and send back an XML with an errorcode if something went wrong.

So basically use the HTTP errorcodes for the service, and use the API errorcodes for it's content.


Therefor I'd like to ask you to revert the recent HTTP 403 errorcode on API errors change.

Thanks for reading, Cyerus.


ps. It would also be an improvement if we can actually retrieve the XML page containing the API error when receiving an HTTP 403 errorcode. Currently it only displays a simply white page with the HTTP 403 errorcode as content. Personally I'm not a big fan of this solution, but I'll list it here as it would still be a big step forward compared to the current situation.
xHjfx
The Legion of Spoon
Curatores Veritatis Alliance
#29 - 2013-07-17 21:59:25 UTC  |  Edited by: xHjfx
I'd rather they made it more sane.

401 unauth for bad key
403 forbidden for bad access mask or alternatively and probably more correct specify key invalid or access mask invalid
400 bad syntax/missing parameter I.e trying to query a char ID with no name specified

500 for server unable to reply?
503 for downtime?

This is what I assumed would be implemented as it serves a logical replacement albeit with less error info.
diabeteman
Diabete Studios
#30 - 2013-07-23 22:00:08 UTC  |  Edited by: diabeteman
I agree with Cyerus !!!!

HTTP errors are for bad or malformed HTTP requests. Not for bad underlying data.

It means that getting 40X errors when the provided keyID is not an integer or if one HTTP parameter is missing (characterID for example) is OK. But getting 40X errors because someone tries to get /account/APIKeyInfo.xml.aspx with an expired or non-existant key is not (the request was not bad or malformed).

Unless you provide a consistent system with HTTP 40X errors mapped to real API problems (a different one for each API problem which will then become part of the API) I think the previous system: "HTTP 200 when the API servers are able to respond something and API errors contained in the XML" makes more sense.

PS: I can only speak for myself but think that a lot of third party apps are currently broken because of this change :)

Initiator and CTO of Eve Corp. Management

Ajurna Jakar
Ajurna Jakar Corporation
#31 - 2013-07-24 23:11:05 UTC
Just as an example of the previous issue. contractitems is no longer working correctly for all contracts.
it's just returning a 400 error. for no good reason. i tried to manually request the page and no joy. not even a hint of what might be wrong.
This seriously effects what we can do as third party developers, we cant tell the difference between api being broken and a bad key. this ends up with more bad requests on your system which im sure you already want to avoid.

http://eve-corp-management.org/ 

Goren Styne
Different Like You
#32 - 2013-07-27 04:48:30 UTC
Cyerus wrote:


Therefor I'd like to ask you to revert the recent HTTP 403 errorcode on API errors change.



+1

This change caused some applications to break, for instance eve-bb. We have been debugging a evebb forum issue and the root cause is the 403 error if a member deletes an API key. This software is expecting the error code in the XML data and a 200 response. A 403 header implies that there is no permission to access the script or the resource, it does not say that the api key was deleted (Which absolutely should stay in the XML response not the HTTP Header)

Goren Styne CEO Different Like You

Raath Nambode
Sebiestor Tribe
Minmatar Republic
#33 - 2013-07-30 11:19:47 UTC
Goren Styne wrote:
Cyerus wrote:


Therefor I'd like to ask you to revert the recent HTTP 403 errorcode on API errors change.



+1



++1

My own web apps have in built error handling to disable expired keys, remove bits from the access mask and more importantly the entire stack is designed to co-operate with the cache expiry timer so that it won't constantly spam the server with useless requests.

Currently I have no way of verifying what the errors are or how to handle them. Please please please prism, revert this change. Surely adding a 403 header to the XML error response would have been easier to do than to completely obliterate such an important mechanic that the API error handling is???

Wormhome Navigation - http://www.staticmapper.com Industrial Management - http://industry.darkshadowindustries.com Follow me on twitter https://twitter.com/staticmapper

Lake
The Praxis Initiative
Gentlemen's Agreement
#34 - 2013-07-31 23:49:29 UTC  |  Edited by: Lake
TLDR: I agree. Give us an HTTP 200 and return an API error code like before.

I have no small amount of error handling code that has been lobotomized. I could previously tell a user a great deal of detail about why their API key wasn't working. Now I just have to shrug and say "I dunno, try something else." Until the lobotomy my applications have simply been treating this as a really long API downtime/failure since that's typically when we got HTTP error codes in the past.

https://api.eveonline.com/eve/ErrorList.xml.aspx

As far as I can tell so far the entire 2xx range of API errors are now masked by an HTTP 403. And while debugging changes to mitigate this I've found I now get an equally inscrutable HTTP 400 Bad Request in place of what was often at least moderately useful in the past.
CCP Prism X
C C P
C C P Alliance
#35 - 2013-08-06 11:40:26 UTC
Just got back from vacation. I see there are some annoyances still out there. I'll take a look as soon as I've reaccustomed to having to work for a payheck. Blink
Olivia Hume
Perkone
Caldari State
#36 - 2013-08-06 12:06:52 UTC  |  Edited by: Olivia Hume
Lake wrote:
TLDR: I agree. Give us an HTTP 200 and return an API error code like before.


Please, no. Only return 200 for successful request. Return a 4xx for bad request or 5xx for server errors, and in both case return a old API error code.
CCP Prism X
C C P
C C P Alliance
#37 - 2013-08-06 12:31:16 UTC
Olivia Hume wrote:
Lake wrote:
TLDR: I agree. Give us an HTTP 200 and return an API error code like before.


Please, no. Only return 200 for successful request. Return a 4xx for bad request or 5xx for server errors, and in both case return a old API error code.


That would be something I'd want to aim for. But apparently there are some further concerns with that that I'll have to look into.
Lake
The Praxis Initiative
Gentlemen's Agreement
#38 - 2013-08-16 02:41:20 UTC
Olivia Hume wrote:
Lake wrote:
TLDR: I agree. Give us an HTTP 200 and return an API error code like before.


Please, no. Only return 200 for successful request. Return a 4xx for bad request or 5xx for server errors, and in both case return a old API error code.


While I agree that would probably have been the best course of action from the start there is now a massive codebase out there (some of it mine, most of it not) that doesn't expect a valid APIv2 XML response (with more detailed APIv2 error information) when it gets anything other than an HTTP 200 status.

I don't think it's worth it even though it's not a huge deal to alter that behavior. Though I was actually surprised how much it would mess with the "flow" of Entity's eveapi.py library (that quite a few people use) to handle HTTP errors as anything other than a ServerError and pass the APIError data up the chain. Though I was admittedly a bit tired when looking at it so that could just have been a case of the dumbs =p
Malus Sentio
The Scope
Gallente Federation
#39 - 2013-10-02 18:42:30 UTC
Quote:
Kill log exhausted (You can only fetch kills that are less than a month old): New kills will be accessible at: 2013-10-02 19:31:08. If you are not expecting this message it is possible that some other application is using this key!


So we can only ever go back 1 month?
What about people who want to write alternative killboards, is there a way to pull history?
Squizz Caphinator
WiNGSPAN Delivery Network
#40 - 2013-10-02 18:45:44 UTC
Malus Sentio wrote:
Quote:
Kill log exhausted (You can only fetch kills that are less than a month old): New kills will be accessible at: 2013-10-02 19:31:08. If you are not expecting this message it is possible that some other application is using this key!


So we can only ever go back 1 month?
What about people who want to write alternative killboards, is there a way to pull history?


Probably not what you're looking for but zKillboard provides an excellent API you can use to get some of your past kills.
http://zkillboard.com/information/api/

Various projects I enjoy putting my free time into:

https://zkillboard.com | https://evewho.com

Previous page123Next page