| Pages: 1 [2] :: one page |
|
|
| Author |
Thread Statistics | Show CCP posts - 11 post(s) |
Ajurna Jakar
Jian Products Engineering Group
Tribal Band
15
   |
Posted - 2013.07.24 23:11:00 -
[31] - Quote
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
6
|
Posted - 2013.07.27 04:48:00 -
[32] - Quote
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
Dreddit
Test Alliance Please Ignore
28
|
Posted - 2013.07.30 11:19:00 -
[33] - Quote
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
46
|
Posted - 2013.07.31 23:49:00 -
[34] - Quote
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
1293
|
Posted - 2013.08.06 11:40:00 -
[35] - Quote
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. 
@CCP_PrismX
EVE Database Developer and Expert Ranter
Member of Team Pony Express |
|
Olivia Hume
Hoover Inc.
Test Alliance Please Ignore
6
|
Posted - 2013.08.06 12:06:00 -
[36] - Quote
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
1293
|
Posted - 2013.08.06 12:31:00 -
[37] - Quote
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.
@CCP_PrismX
EVE Database Developer and Expert Ranter
Member of Team Pony Express |
|
Lake
The Praxis Initiative
Gentlemen's Agreement
84
|
Posted - 2013.08.16 02:41:00 -
[38] - Quote
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
Oberon Incorporated
RAZOR Alliance
2
|
Posted - 2013.10.02 18:42:00 -
[39] - Quote
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
Woopatang
111
|
Posted - 2013.10.02 18:45:00 -
[40] - Quote
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 time into:
http://eve-kill.net | http://zkillboard.com | http://evewho.com | http://evechatter.com | http://skillq.net |
|
|
Malus Sentio
Oberon Incorporated
RAZOR Alliance
2
|
Posted - 2013.10.03 22:12:00 -
[41] - Quote
Thanks for the response. Yes, your API does look great however its not really the path I want to go down.
I have posted in the "king is dead" thread to hopefully get a response. |
Jade III
Angry Mustellid
88
|
Posted - 2013.10.17 14:04:00 -
[42] - Quote
Can you give us a file for the API please? Thanks.
My adventure blog: http://lonewolfadventures.wordpress.com/ |
Florian Lousberg
Dubiose Briefkastenfirma
0
|
Posted - 2013.11.21 17:21:00 -
[43] - Quote
Thanks for adding the ownerTypeIDs, that's a very useful feature!
But looking through my WalletJournal, I found some irregularities. Sometimes (but not always!) for Market Escrows (refTypeID=42) the owner1TypeID and owner2TypeID seem to be the wrong way around:
The API wrote:< row
date="2013-11-20 21:47:39"
refID="8520035179"
refTypeID="42"
ownerName1="Florian Lousberg"
ownerID1="92727955"
ownerName2=""
ownerID2="0"
argName1=""
argID1="0"
amount="-17955000.00"
balance="[...]"
reason=""
taxReceiverID=""
taxAmount=""
owner1TypeID="2"
owner2TypeID="1378"
/ >
In this example, Owner1 (Florian Lousberg, that's me) is a character, but owner1TypeID=2 says it's a Corporation. The correct typeID for a Gallente/Intaki Character would be 1378, which is in owner2TypeID.
Most of my refTypeID=42 journal entries behave like this, there are only a few where owner1TypeID is set correctly to 1378.
Is that an API bug, or an intended feature I just don't understand? |
|
|
| |
|
| Pages: 1 [2] :: one page |
| First page | Previous page | Next page | Last page |