EVE Technology Lab

Could you add list of base urls to https://developers.testeveonline.com/resource/crest ? Also, https://developers.testeveonline.com/resource/crest/public-crest need some explanation.

EDIT.

I mean, it would be very helpful to know:

Are those limits applied for ip or for application? For example, I may have different apps at one host, so should I worry about total amount of requests?

What is "burst"?

Is there any signs that I am near limit? Maybe you could add some header with numbers to crunch.

I'm using eveapi ( https://github.com/ntt/eveapi ) python library for XML api along with my own caching linrary ( https://github.com/brammator/glomp )

Storing api call results with (host, path, params) key goes well with XML eve api: it separates TQ from SiSi by host, inherently does security (via keyID=, vCode= in api call params) etc.

It doesn't go well with CREST: security code ("bearer" token) TTL is too short and passed differently (via HTTP header, not api call parameter), enpoints are duplicated on different hosts ("public" and "authed").

I could rewrite CREST API library to add refresh_token or app secret code to "params" list, but is it good solution? And what about data host deduplication?

There is some good libs in development, I even abandon mine in favor of one of them ;-) Data is data, anyway, and api libs look pretty familiar, XML and CREST.

Here's one example of how the current API design is impractical for users:

The scenario is loading the solarsystems endpoint for a given system name, a fairly standard task.
But thanks to the RESTful design, there's no endpoint listing systems by ID and name, but rather a hierarchy of regions pointing to constellations pointing to solar systems. Since we don't know in which region or constellation the system is, you have to traverse all of them, including the solarsystem endpoints themselves to get the system name, resulting in over 9200 calls to the API.

Of course the consumer can massage the data into a useful form and cache/persist that, but the problems of what should be a trivial API remain. Especially when you consider it is intended to be able to replace the SDE at some point. This is symptomatic of the problems one keeps uncovering while working with CREST, so I'd like to point to this article (API design matters), ask the CREST developer(s) to read it and to memorize "Is there anything I could reasonably do for the caller I am not doing?".

Another example is the wars endpoint:
The endpoint lists over 400k wars. There's no attribute by which you can find/filter them like dates, aggressor or defender. Guess what you're forced to do to find specific ones...

That's a common problem with RESTful APIs. Because you have to be able to arrive at an entry URI then walk through the API, it has to be broken down into the steps it takes to provide you the information with each step, then to go back up a level you need to backtrack. They are great for providing individual pieces of functionality or information, but pretty terrible at just providing a bulk of information, which the regular EVE API does quite well. I wonder how useful to sites like EVE-central the market API will actually be in the long run, as I do for zKB and kill data if that is ever made fully browsable.

So in marketSellOrders, the type object contains id_str & id fields, but in itemTypes only href and name fields are found. Are these not supposed to be the same object? It would be really helpful to find the id_str and id fields in the itemTypes endpoint. Thanks.

The list of endpoints includes one for characters, but it's not implemented yet.

It's coming, but so far, of the main 3, we only have alliances (released because it was needed for the AT stuff).

FoxFour - Can we have closed entities included in the ContactList XML? or a Standings endpoint :p

I poked you on this ages ago but it appears to have gotten lost on your list :(

1) Maybe, I will look into it.
2) Dunno, didn't create it.
3) For the options call?