EVE Technology Lab

Nice stuff

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.

Just here to give PrismX a real manhug!

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.

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 :)

+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)

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.

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

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/