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.
 

EVE API and Public CREST discussion

First post First post First post
Author
Previous Topic Next Topic
Querns
Science and Trade Institute
Caldari State
#121 - 2014-04-24 17:11:03 UTC
Lors Dornick wrote:
Querns wrote:


In any case, it's just fluff; 0,0,0 is detectable and works.

While I agree that it's fluff, it also raises some rather hairy and uncomfortable memories of unexpected and unexplainable errors crashes caused by Ye Olde "let's indicate error by returning a value that never ever will be valid (at least not in the current design and according to what we know now)".

Some explicit "this line is false/failed" can't be that much more expensive and far safer.

And besides, the latter is "Good Design", instead of "it effing works doesn't it?" ;)

Well, the x/y/z attributes would have to have SOMETHING there, but yeah -- I agree.

This post was crafted by the wormhole expert of the Goonswarm Economic Warfare Cabal, the foremost authority on Eve: Online economics and gameplay.
Max Kolonko
Caldari Provisions
Caldari State
#122 - 2014-04-24 17:58:22 UTC  |  Edited by: Max Kolonko
Querns wrote:
Lors Dornick wrote:
Querns wrote:


In any case, it's just fluff; 0,0,0 is detectable and works.

While I agree that it's fluff, it also raises some rather hairy and uncomfortable memories of unexpected and unexplainable errors crashes caused by Ye Olde "let's indicate error by returning a value that never ever will be valid (at least not in the current design and according to what we know now)".

Some explicit "this line is false/failed" can't be that much more expensive and far safer.

And besides, the latter is "Good Design", instead of "it effing works doesn't it?" ;)

Well, the x/y/z attributes would have to have SOMETHING there, but yeah -- I agree.



Also agree - and if that is outside of possibility I'm ok with #1

Read and support: Don't mess with OUR WH's What is Your stance on WH stuff?
Polarina
EVE University
Ivy League
#123 - 2014-04-24 23:47:14 UTC
CCP FoxFour wrote:
OK, I have a fix for the locations endpoint shitting itself when an invalid ID is supplied. The question is which would you guys prefer.

1) Return the invalid items with blank name, and 0's for X, Y, Z
2) Drop invalid items from the return all together.

Let me know which you think would be better. :)

The second option is more sane. Comparing the list of IDs requested and IDs returned is trivial, if needed. Often, one does not even need to know any items failed, just process what was returned. The first option has the possibility of biting someone in the future.

Imagine, someone that doesn't know that the API treats invalid IDs by returning an empty name. Now, imagine the same person looking through all the empty names in his database. That person attempting to diagnose this would have no idea what would be causing this, even by looking at the XML returned by the API.

Where are my clothes?
CCP FoxFour
C C P
C C P Alliance
#124 - 2014-04-25 00:35:52 UTC
Polarina wrote:
CCP FoxFour wrote:
OK, I have a fix for the locations endpoint shitting itself when an invalid ID is supplied. The question is which would you guys prefer.

1) Return the invalid items with blank name, and 0's for X, Y, Z
2) Drop invalid items from the return all together.

Let me know which you think would be better. :)

The second option is more sane. Comparing the list of IDs requested and IDs returned is trivial, if needed. Often, one does not even need to know any items failed, just process what was returned. The first option has the possibility of biting someone in the future.

Imagine, someone that doesn't know that the API treats invalid IDs by returning an empty name. Now, imagine the same person looking through all the empty names in his database. That person attempting to diagnose this would have no idea what would be causing this, even by looking at the XML returned by the API.


My reasoning for it, and this maybe isn't a good reason, is that thats how we handle invalid things on our other endpoints. Give a bad ID to the eve/OwnerName endpoint It just returns blanks but still returns that ID.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Polarina
EVE University
Ivy League
#125 - 2014-04-25 01:01:19 UTC
CCP FoxFour wrote:
My reasoning for it, and this maybe isn't a good reason, is that thats how we handle invalid things on our other endpoints. Give a bad ID to the eve/OwnerName endpoint It just returns blanks but still returns that ID.

Is it? I can't find a consistent handling of ID errors across the API.

  • /char/CalendarEventAttendees.xml.aspx silently ignores invalid event IDs. Also, why does it have a 15 second cache timer?
  • /char/MailBodies.xml.aspx silently ignores invalid message IDs.
  • /char/NotificationTexts.xml.aspx gives an XML element <missingIDs> with a comma separated list of invalid IDs, rest is returned normally.
  • /eve/CharacterID.xml.aspx gives characterID zero on invalid names.
  • /eve/CharacterName.xml.aspx gives the characterName "Unknown Item" on invalid character IDs.

Where are my clothes?
Drailen
Doomheim
#126 - 2014-04-25 07:16:32 UTC
CCP FoxFour wrote:
OK, I have a fix for the locations endpoint shitting itself when an invalid ID is supplied. The question is which would you guys prefer.

1) Return the invalid items with blank name, and 0's for X, Y, Z
2) Drop invalid items from the return all together.

Let me know which you think would be better. :)

Option 2.

If you've already identified the invalid IDs server side, it doesn't make much sense to return them for us to check every one to do the same. Seems much cleaner just to return a valid list.
Lors Dornick
Kallisti Industries
#127 - 2014-04-25 15:27:01 UTC
Polarina wrote:

The second option is more sane. Comparing the list of IDs requested and IDs returned is trivial, if needed. Often, one does not even need to know any items failed, just process what was returned. The first option has the possibility of biting someone in the future.

Imagine, someone that doesn't know that the API treats invalid IDs by returning an empty name. Now, imagine the same person looking through all the empty names in his database. That person attempting to diagnose this would have no idea what would be causing this, even by looking at the XML returned by the API.


I agree that the second option is more sane based on the somewhat sad fact that using any form of web based API can (and will) generate all kinds of weird results, so a good application should be written to expect weird, wrong and/or non-existent replies.

And maybe even more so in this case.

Eve Online is a game, sure internet pixel spaceships are serious business, but it's still a game, not exactly a business critical application.

Releasing a somewhat documented static DB and letting Devs to tinker with a somewhat documented API is a smart move to keep curious (and often very clever) users away from having to dissect the game over and over again to extract data and write tools that do useful stuff for all.

But there has to be a balance, there's only so much that we can nudge CCP to invest in this.

So we have to find ways to get the data we want, when we want it and in the way we want it, without pushing our caring Devs to a collision course with their bosses.

Polarina wrote:
CCP FoxFour wrote:
My reasoning for it, and this maybe isn't a good reason, is that thats how we handle invalid things on our other endpoints. Give a bad ID to the eve/OwnerName endpoint It just returns blanks but still returns that ID.

Is it? I can't find a consistent handling of ID errors across the API.

And I think you've hit it on the head there.

When using the API it's down to the application to handle whatever weird result a call gets.

Sure, asking for a consistent error behaviour is natural and good, but expecting it is bad coding practice.

Or to quote an old hero of mine "all APIs works best when both sides expect the other side to be morons".

CCP Greyscale: As to starbases, we agree it's pretty terrible, but we don't want to delay the entire release just for this one factor.
CCP FoxFour
C C P
C C P Alliance
#128 - 2014-04-29 10:50:35 UTC
Patch notes for todays deployment are up on the first page of this thread. Here they are as well though:

2014/04/29:

  • [EVE API] Adding endpoints for PI to the EVE API
  • [EVE API] /char/PlanetaryColonies added
  • [EVE API] /char/PlanetaryPins added
  • [EVE API] /char/PlanetaryRoutes added
  • [EVE API] /char/PlanetaryLinks added
  • [EVE API] All PI related endpoints require having access to the assets list
  • [EVE API] All PI related endpoints, except colonies, require a planetID in the URL
  • [EVE API] All PI related endpoints require a characterID be supplied
  • [EVE API] *CCP FoxFour hopes he has not screwed up access requirements horribly*


This should all be live as soon as TQ is back from downtime.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Vectara Lock
Sleeper Slumber Party
#129 - 2014-04-29 21:19:46 UTC
CCP FoxFour wrote:
Patch notes for todays deployment are up on the first page of this thread. Here they are as well though:

2014/04/29:

  • [EVE API] Adding endpoints for PI to the EVE API
  • [EVE API] /char/PlanetaryColonies added
  • [EVE API] /char/PlanetaryPins added
  • [EVE API] /char/PlanetaryRoutes added
  • [EVE API] /char/PlanetaryLinks added
  • [EVE API] All PI related endpoints require having access to the assets list
  • [EVE API] All PI related endpoints, except colonies, require a planetID in the URL
  • [EVE API] All PI related endpoints require a characterID be supplied
  • [EVE API] *CCP FoxFour hopes he has not screwed up access requirements horribly*


This should all be live as soon as TQ is back from downtime.


It looks like /char/PlanetaryPins caches and serves the same result even if you supply different planetID values.
Grand Formage
The Planetary Baron Society
#130 - 2014-04-30 00:21:21 UTC
CCP FoxFour wrote:
Patch notes for todays deployment are up on the first page of this thread. Here they are as well though:

2014/04/29:

  • [EVE API] Adding endpoints for PI to the EVE API
  • [EVE API] /char/PlanetaryColonies added
  • [EVE API] /char/PlanetaryPins added
  • [EVE API] /char/PlanetaryRoutes added
  • [EVE API] /char/PlanetaryLinks added
  • [EVE API] All PI related endpoints require having access to the assets list
  • [EVE API] All PI related endpoints, except colonies, require a planetID in the URL
  • [EVE API] All PI related endpoints require a characterID be supplied
  • [EVE API] *CCP FoxFour hopes he has not screwed up access requirements horribly*


This should all be live as soon as TQ is back from downtime.


It is about time the "something" was done that had "anything" to do with PI. Now all I have to do is figure out what all the stuff above means and how can I use it to my benefit.

What I really want to know is when is PI itself going to have its next iteration. While amazingly little is actually broken in my opinion, there is a massive number of things that can be improved upon for reason of intelligent functioning. Additionally, there are quite a few things that can be done that would bring certain elements to the next logical step (t1 to t2 advancement, not referring to the materials). I have created a forum for such discussions @ http://www.kinzland.com/eveoforums/jtr/. It is new so not a lot yet but hopefully it will grow.
CCP FoxFour
C C P
C C P Alliance
#131 - 2014-04-30 01:53:55 UTC
Vectara Lock wrote:
CCP FoxFour wrote:
Patch notes for todays deployment are up on the first page of this thread. Here they are as well though:

2014/04/29:

  • [EVE API] Adding endpoints for PI to the EVE API
  • [EVE API] /char/PlanetaryColonies added
  • [EVE API] /char/PlanetaryPins added
  • [EVE API] /char/PlanetaryRoutes added
  • [EVE API] /char/PlanetaryLinks added
  • [EVE API] All PI related endpoints require having access to the assets list
  • [EVE API] All PI related endpoints, except colonies, require a planetID in the URL
  • [EVE API] All PI related endpoints require a characterID be supplied
  • [EVE API] *CCP FoxFour hopes he has not screwed up access requirements horribly*


This should all be live as soon as TQ is back from downtime.


It looks like /char/PlanetaryPins caches and serves the same result even if you supply different planetID values.


HAHAHAHAHA yes it would and I know why even at 2AM after a long night of drinking. I am very sorry about that and will see if I can get a fix out ASAP. That should actually be the case for all of them.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Lors Dornick
Kallisti Industries
#132 - 2014-04-30 03:31:12 UTC
CCP FoxFour wrote:


HAHAHAHAHA yes it would and I know why even at 2AM after a long night of drinking. I am very sorry about that and will see if I can get a fix out ASAP. That should actually be the case for all of them.

Hope you had a nice evening Socks.

And you can be allowed to sleep in.

You've done well ;)

The pressure will increase once we've let you recover from fanfest ...

CCP Greyscale: As to starbases, we agree it's pretty terrible, but we don't want to delay the entire release just for this one factor.
CCP FoxFour
C C P
C C P Alliance
#133 - 2014-04-30 16:26:59 UTC
Deploying a fix for the PI cache issue.... now(ish... deployment is running so give or take a minute from post). >.<

Let me know if it breaks anything else for you, think we are good now though.

Tried to get this out sooner, just been very busy with Fanfest prep today so sorry for the delay. :)

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Leebe
The Scope
Gallente Federation
#134 - 2014-05-01 11:46:42 UTC  |  Edited by: Leebe
I noticed the "columns" attribute in the rowset of PlanetaryPins mention "headRadius" but it is missing from the rows.
(also the columns don't mention longitude and latitude)

columns="pinID,typeID,typeName,schematicID,lastLaunchTime,cycleTime,quantityPerCycle,installTime,expiryTime,headRadius,contentTypeID,contentTypeName,contentQuantity

row pinID="1011768140479" typeID="2848" typeName="Barren Extractor Control Unit" schematicID="0" lastLaunchTime="0001-01-01 00:00:00" cycleTime="15" quantityPerCycle="21296" installTime="2013-08-25 17:07:49" expiryTime="2013-08-25 18:37:49" contentTypeID="0" contentTypeName="" contentQuantity="0" longitude="-3.11917281639712" latitude="-3.11917281639712"
Aithnee Hayes
Aideron Robotics
Aideron Robotics.
#135 - 2014-05-02 01:02:08 UTC
I'm trying to access /char/PlanetaryColonies but it is returning an empty colonies rowset for both of my characters that actually have PI colonies. I'm using an API with all feeds on...

Anybody else had this problem?
brammator
SUB ZERO.
#136 - 2014-05-03 19:12:19 UTC  |  Edited by: brammator
Idea: add Hardwirings info to char/CharacterSheet/AttributeEnhancers list

Idea: reveal Jump Clones (position, implants, hardwirings) info
Description: Could be separate endpoint, because char/CharacterSheet is HUGE already. Also Jump Clone timer, please.

Idea: split char/CharacterSheet into smaller endpoints
Description: or just add endpoints CharacterSkills, CharacterCertificates, CharacterRoles and CharacterBriefSheet. Last one would be CharacterSheet minus three previously named portions.

Idea: add expiration and account/character fields to api-creating uri
Description: something like api-key/CreatePredefined?accessMask=9830414/account/false/false
Polarina
EVE University
Ivy League
#137 - 2014-05-04 00:27:19 UTC
brammator wrote:
Idea: add expiration and account/character fields to api-creating uri
Description: something like api-key/CreatePredefined?accessMask=9830414/account/false/false

If there's anything I would like other than the accessMask parameter, is a vCode parameter. One problem I face is how to authenticate players that register into my tool, that they really are who they claim to be and not an imposter.

What I currently have is to require a key with accessMask set to zero (0). Really useless, so unlikely anyone but the player in question has one. While simple, the owner of one 3rd party tool can impersonate said character on another 3rd party tool that uses the same method.

If I could instead just say "Create a key with the verification code Rugludallasúpa", where Rugludallasúpa is some random vCode I control and generate myself, it would be an effective way of authenticating users.

Where are my clothes?
Polarina
EVE University
Ivy League
#138 - 2014-05-04 02:57:47 UTC
Can the attribute "description" be added to /char/Medals.xml.aspx for the "currentCorporation" rowset? It is present in the "otherCorporations" rowset.

The legacy API keys granted access to /corp/Medals.xml.aspx, getting the description was easy and trivial from that endpoint. With the new customizable keys, it is not possible to get the medals' descriptions without a corporation key form a director or the CEO.

Where are my clothes?
Icahmura Hasaki
Perkone
Caldari State
#139 - 2014-05-05 12:38:56 UTC
Can you change the returned HTTP status code to something more sensible than 000 when /char/killlog is exhausted? The .NET WebRequest/WebClient seem to be unable to deal with this, and won't even let me fetch the response body. 000 is a custom code for client-abort, and not part of any standard.

Returning 500 or 503 would make more sense. Smile

Developer of EveLib and EveAuthUtility
CCP FoxFour
C C P
C C P Alliance
#140 - 2014-05-06 10:47:20 UTC
Icahmura Hasaki wrote:
Can you change the returned HTTP status code to something more sensible than 000 when /char/killlog is exhausted? The .NET WebRequest/WebClient seem to be unable to deal with this, and won't even let me fetch the response body. 000 is a custom code for client-abort, and not part of any standard.

Returning 500 or 503 would make more sense. Smile


I can look, but no promises.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.