EVE Technology Lab

This is a copy of this post. Created a seperate thread to make sure this problem receives the attention it deserves.

Up until the API server update of Odyssey 1.0.10 (see this thread) 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.

Completely supported.

Meaningful error messages are needed.

I can understand thowing a http error message, but there needs to be something in the body saying /what/ the problem is.

I could understand if CCP meant that error 40x was their API servers failing.... but they you get Internal server error 500 if something major goes... Error 403 means you either got a bad key or a bad access mask.

Invalid characterID should come back as bad request IMHO.

It's no where near doom and gloom, just not as informative as the old system - you just actually have to bother to re code for the changes.

CCP broadsided us with the change (we were using Pheal for our project) and encountered the error - a few lines later and it was sorted.

No need to repost, devs are already working on it.

Spoke with PrismX a bit ago who said it wasn't on his list just yet. In other words: soon(tm). This problem needs to be in the spotlight in order to be looked at, as it's a major pain in it's current form.



Recoding isn't that easy, as we are missing information. Nothing is solid anymore, it has become guesswork. For example: Does a 403 mean that the user isn't part of fw using FacWarStats call, or is the characterId wrong?
What about spam control? Can't really stop quering if the API 904 is shown as an HTTP 403...

Internally the API errorcoded are still used, they just aren't displayed anymore, which I hope to change.

I didn't like it at first but I've actually found it has simplified TEA somewhat.

Basic process now is :

1/ get Keyinfo - 403 at this point is expired or non existant key so stop and mark bad in DB & never check again using the automatic poll
2/ check apimask is appropriate based on mask returned in xml from keyinfo - currently continue processing but in future may change this to stop processesing rules.
3/ get corpinfo, charactersheet, characterinfo, facwarstatus if any of these return a 403 then don't try and evaluate a TEA rule based on the info fetched from that api call.

This is not a sky is falling moment we just have to be a little smarter about how we code our apps rather than relying on CCP to do the work. Given that I've seen much fewer 500/404/timout errors from CCP's API servers since this went it I'm more than happy with the trade off.

How could that possibly be the case? You get just less info about errors than before, so there's literally nothing you can do now that you couldn't have done before.

That's great for you, but apart from the fact that there's still more guesswork in this than necessary (see my above post) there are usecases where you don't want to call half a character's API. If you only want to call 1 page then using a KeyInfo first for verification already doubles the server load.

What work? The API server already knows the reason why it rejects a request, it only has to tell us. That's not work, that's server programming 101.

Like xHjfx you kinda make it sound like we are just too lazy to adapt to the new system which simply isn't the case. If we minded work we wouldn't have become unpaid 3rd party devs in the first place. We just dislike working with a system that gives us less info than it could for no good reason. If they want to keep HTTP error codes instead of XML messages that's fine by me, but then do it right and map every single error to a distinct code and document that somewhere. Sending no XML message and mapping lots of different errors to the same HTTP code was a bad idea and should get fixed.

Sorry I was too rushed this morning and expressed myself poorly. As you say there are many use cases and in the case of TEA it forced me to change the approach it took which resulted in things being simpler. That said it did result in a lot of time spent rewriting which I could have spent far more productively ... ie playing the damn game :)

I'm building a new app and the lack of data offered from these 403s is less then beneficial. The old error machinery was much more efficient for my purposes and I would greatly support its return.

Not true. They are not currently working on any of it. CCP Prism X says "I just don't have the bandwith to take a look at the API right now."

This is still a low-priority issue for CCP more than 4 months after it was identified as a big problem for 3rd-party developers. The more people squawk about it the better. And by the way, how does this square with what CCP Seagull said 9 months ago in her We Loves Us Some 3rd Party Developers devblog? Quoting the last part of paragraph 2:


How does that awesome committment of words seem to be working out for all the 3rd-party developers lately? 9 months and we've got a lot of lip service and no ******* action. God bless CCP Prism X, he realizes things aren't right and something needs to be done. But one man cannot accomplish anything when higher ups have decreed that Dust needs a bigger budget for the forseeable future. This **** pisses me off, sorry. Watch what they do, not what they say.