EVE Technology Lab

So from what I can pick up through google and forum searches is that CCPs plans are to replace the API calls that require your Vcode etc with crest, eventually

So as I am currently writing a rather large spreadsheet containing a bunch of different info I should, I assume, use Crest whenever possible instead of API calls.... which kinda sucks cause it means learning everything about crest lol.


But one other question pertaining to Crest... will it replace the SDE Dumps as well? For instance I currently get a few tables from fuzzwork and throw the needed tables into a directory with excel then reference those files, it makes updating easy as I dont really need to do anything other than download and extract some files.

So as I'm writing a new spreadsheet instead of using say invtypes.xls would it be smarter to use crests market items link?

I would imagine that would slow things down some as it would be yet another link via internet but on the flip side it would make updating my spreadsheet even easier by eliminating the downloading of a table.


.. invtypes was just a quick example I also use marketgroups, stastations, metagroups to name just a few, I just wanna try to make sure I have forward compatibility... I dont want to have to scrap this and start from scratch in a few months or a year or so.


So thoughts? How Crest happy should I get compared to API calls and SDE Dumps?


Thanks.

so Im better off using SDE info above crest data ie: invtypes

I've never actually heard of someone complaining that the cache timers are too short before.
If something is cached for 5 minutes, nobody is forcing you to update that often if you don't actually use it that often.

If you do use static data from CREST (systems, types, etc), the best thing to do would be to invalidate your cache any time the version changes.
serverVersion is on the root so that's just a single request. I personally just use a hash of that and include it in my keys so I automatically get a cache miss, but if you don't want older versions hanging around in memory then just check that separately and invalidate your caches once it changes.

The thing is that CREST requires of clients to implement a caching logic that will respect the caching times specified in the responses, but then makes bad use of it. Static data comes with a 20 minute cache timer. Of course you can hardcode that for some response types the cache timer shall be overridden by whatever logic or value you want, but that ugly as it makes your code less generic and is basically a crutch for an already existing mechanism that isn't used properly. CREST should set cache timers that align with downtimes for static data, for instance.
Thats what I do btw: A second layer of caching above the response cache, that caches the gathered multipage responses, reindex by ID, etc, with expiry on next downtime...


Whatever is available in the SDE I would of course get from there, but things like the regional market hrefs (which we are expected to follow), aren't.