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.
 

Call for CREST university project ideas
Author
Previous Topic Next Topic
Executus Primus
Tyrannis Enterprises
#1 - 2016-03-16 17:15:13 UTC
Hi,

i am currently evaluating whether i could use the EVE CREST API to teach computer science bachelor students. It is a course for "Web Engineering & Security" and one topic i would like to get across is how to access and design modern REST/JSON APIs. Now i could make up something synthetic, but using the API of a video game might be more fun. The idea would be to make a team of 3-4 students to have a programming project for one semester. The EVE API could provide the "access and work with REST API" experience.

I got the idea when reading about the programming challenge.

So i am currently collecting ideas for projects that are reasonably challenging, that:

* would access the API to pull data
* provide its own API (this could be like EVE API <-> client:service:server(restfull api) <-> webapplication), the students would have to program the service and the app
* ideally include some applied cryptography (i could explain oauth which is included as SSO, but that is a little slim)

I am looking for ideas for projects that could be fun, useful (in the context of eve) and reasonably challenging for a team of 3-4 that work on it part time during the semester. I had a quick glance at the API but i don't have a full overview yet what data is exported vis a vis the XML API and what is possible with that. I get that market data is exported, system status, fitting and war stats:

So at the top of my hat i thought about:

* market analysis tool
* dynamically updating sov map
* alliance fitting tool
* war tracking tool

This is just some first ideas, so therefore i am looking for input from people who have actually worked with the API already and therefore have an idea whats possible in terms of data and what isn't. Thanks for the input.

Exe
Pete Butcher
The Scope
Gallente Federation
#2 - 2016-03-16 19:35:45 UTC
Well, you really shouldn't take CREST or XML API as examples, unless you want to show how to NOT design an API. Both undocumented; XML API is full of inconsistencies and strange hacks (-2 quantity means your item is a BPO - wtf?); CREST follows HATEOAS, which is unusable for the most of 3rd party apps (discovery centric interface for data which is already discovered by the SDE and game rules); constant failures since going live... Sometimes it really feels like it was designed by a student who read some blog posts about API design and decided to make one. Sorry for the grim tone, but I've been working with it since the very beginning and I'm really frustrated.

As I conduct design trainings myself at Samsung, I can tell you an example of something done badly is also a valuable thing to teach. Make your students aware of all the dangers involved. You can use CREST as a classic case of the Second System Effect. If you want more specific info of why current situation is bad, I can supply you with all the data you need.

http://evernus.com - the ultimate multiplatform EVE trade tool + nullsec Alliance Market tool
Executus Primus
Tyrannis Enterprises
#3 - 2016-03-17 15:27:45 UTC
Pete Butcher wrote:
Well, you really shouldn't take CREST or XML API as examples, unless you want to show how to NOT design an API. Both undocumented; XML API is full of inconsistencies and strange hacks (-2 quantity means your item is a BPO - wtf?); CREST follows HATEOAS, which is unusable for the most of 3rd party apps (discovery centric interface for data which is already discovered by the SDE and game rules); constant failures since going live... Sometimes it really feels like it was designed by a student who read some blog posts about API design and decided to make one. Sorry for the grim tone, but I've been working with it since the very beginning and I'm really frustrated.

As I conduct design trainings myself at Samsung, I can tell you an example of something done badly is also a valuable thing to teach. Make your students aware of all the dangers involved. You can use CREST as a classic case of the Second System Effect. If you want more specific info of why current situation is bad, I can supply you with all the data you need.


Hi,

thanks for the input. I must admit i just had a first glance at it and i just thought it might be more engaging than to do something synthetic.

Concerning your points:

* undocumented is kind of fine, this is supposed to be a "real life" exercise, so if they have to dig into the API that is fine. I had a look at the basic documentation and my impression was that you could go from there. The Rest API in itself lends itself to discovery, so it shouldn't be too hard.

* HATEOAS is also fine, since that from my point of view is desired in terms what they should learn, regardless how well it lends itself to existing applications

* constant failures? as in availability?

I would very much like to get your input since i just dabbled with the XML API a long time ago and never really "worked" with it. I will send you my contact via evemail. Thanks so much.

Exe
Ortho Loess
Escalated.
OnlyFleets.
#4 - 2016-03-17 19:52:11 UTC
Executus Primus wrote:

* constant failures? as in availability?


That is what he means, yeah.

The contest was marred by a recurring problem which would randomly make the whole of auth'd crest stop working for hours at a time for some people, while fine for others. Still happening and still no info about what might be wrong or even whether the issue has been acknowledged. (It's a 502 error related to proxies see here and here)

I've completely stopped working with crest for now. It got far too annoying not being able to test anything for a whole day's coding session at a time.

There's some random inconsistencies too, e.g.
- It's all supposed to be self discovery from the root, but the root lists a load of endpoints that are not available yet.
- You should never hard code a uri, always walk from the root, however the contacts endpoint requires you to post a fully formed contact object, complete with a uri, which is not available anywhere else.

Remember that in order to really do much with crest you need to have an EVE account and to 'sign' the dev agreement and be able to generate the tokens that allow use of crest you have to have paid for an account at some point.
Aineko Macx
#5 - 2016-03-18 09:46:55 UTC
Pete Butcher wrote:
Well, you really shouldn't take CREST or XML API as examples, unless you want to show how to NOT design an API.

Yeah, CREST commits almost every API design sin I can think of. Might actually be a good study of why API design matters, hopefully enabling some awareness in future developers.

iveeCore 3.0: The PHP engine for industrial activities and CREST library