EVE Technology Lab

Hi devs!

We're prepping for letting you get access to the CREST API documented here https://forums.eveonline.com/default.aspx?g=posts&m=1023703#post1023703 , but we have some questions around how to best do this without causing confusion. We'd love some input from you.

So, we want to get access to the CREST API in the hands of a decent size group of developers - pretty much anyone who's interested and willing to put up with the quirks or the beta should be able to participate. We want you to be able to try things out, experiment with how to integrate CREST APIs in your applications, and generally help us iron out any weird stuff with the API from your perspective.

Question 1: If every player can access CREST stuff through your beta integrations, well, then that's a public release of CREST rather than a beta. Do you guys have some suggestions on how to restrict access so that we don't release access for every player, but you guys can still try things out in a sensible way? Would it for example make sense if you supplied a list of user accounts that you'd like to be able to test CREST from? And then only characters on those accounts would be able to get access tokens?

Question 2: When it comes to the user experience in applications, we're in for a bit of an interesting ride, as users will have to deal with 3 different API authentication methods: Old API keys, Customizable API keys, and then CREST application permissions. Do any of you have thoughts on how you would handle this? Are you thinking to do optional CREST authentication in addition to the API keys for example? We'd like a better idea of this, so that we can figure out how to best spend our efforts in smoothing the transition.

Any thoughts and input appreciated. We'll have more concrete info soon, the current plan (that might change, can't commit to it here) is to roll out the beta with a point release after Inferno - in late June or so.

1) Access tokens for specified accounts sounds fine.
2) Probably add in support for all 3 myself

On the legacy API issue, I understand these are being phased out next spring.

However, currently you can do 'more' withe legacy keys than you can with the new style.

You can't create a key that does all character accounts AND any corps with the new keys. You can only do either all characters or one corp. This means to replicate functionality of a Full Legacy API key you can need upto 4 new keys. It'd be nice if there was an everything option for the new keys.

PS, to the guy above, you can create old keys still if you know the right page. I insist on old keys because for my purposes they are far superior.

Yup we know - that's why it's a beta at first - rather than a full release. We don't expect people to write amazing applications just having access to contacts - but rather it's enough of an example to use for trying integration with CREST. So you should probably come on board later than the beta. :)



CREST is using oAuth. http://wiki.eveonline.com/en/wiki/CREST_Documentation#Authorization

Question 1:
If its just the CREST part you need to restrict access to (oauth might be different), the easiest way to do this is probably to introduce some kind of beta key, that will be send as an additional http header along with the request and is bound to a single character after the first call.
This would allow devs to deal with the question whom to whitelist and you guys at ccp just generate new keys as needed. It would also be much easier to track applications this way, as you could tie them to beta keys.

that would be totally fine with me.
another option would be a sisi rollout. this would be kinda public too, but people wouldn't be working with live data. This would help both sides (you and us) to collect a bit of data on a more realistic usage scale (if we can gather enough users to try it out)


My stance on this is:

Old API Keys: i don't support 'em anymore, and i believe most other apps have switched too.
Crest Auth: we are speaking about the OAuth2 approach here, right? this will be my preferred way of identifying users as soon as its up and running.
Customizeable Keys: generally speaking of Auth API keys where never a good way to auth someone, so this "option" with all the tricks that needed to be done to be sure that the key owner owns the account will be dropped by my apps asap.
Since there is still a need for the keys though, i've looked into a few ideas.

There are a few options on how to migrate, and it depends a lot on what you guys are going todo.
For example one option that involves more work on your end, but would be very nice for the user would be that the OAuth part allows to give access to specific keys through Crest for an application, meaning If i auth through oauth and allow a specific application the right "retrieve key x", and then through crest could get this key so i can use it to access the old API, this would make transition very smooth. But i kinda doubt it fits in your timeframe to do such thing?

One of the things on my private todo list is to create a "Proxy" which accesses the old API but provides the information in CREST style, allowing apps to migrate fully to one access library, and to develop future applications without taking too much care about the legacy API. Now if you cant/wont do the feature i mentioned earlier, one of the services i could provide would be an Authed key storage that works together with that Proxy, so people don't have to enter their custom keys everywhere - however, that will always have the user-trust-issue, so having taken care of OAuth to customkey on your side would take alot of problems out for us app developers.


chat me up if you want more input on any of my suggestions,

regards,
PP

Is there a reason you can't just connect up CREST to Sisi for the beta? Then you don't need to mess around with lists of allowed accounts and whatnot. I don't actually see a reason to do a real beta, just enable CREST on Sisi and let people play with it. It will give you guys a chance to test all of your stuff, including the application registration process.

I also agree with pulling legacy API key support. I can't imagine there are any apps out there that don't support the new style keys, even if some folks above apparently prefer them.

Question 1: Open public release on Sisi - Honestly only dev's are really going to use it and if non-dev player does well thats just a bonus really.

Question 2: Get rid of legacy keys, and build crest authentication into Customizable API keys. (use what you have).

Question 3: Priority :
1) Is there a need? (if only read data is needed then I would not convert to crest)
2) Is added functionality worth it to ratio of users that will benefit
3) Time factor and work load to make it happen.

Functions used to monitor things that affects my char / corp while not logged in, i.e: Skill Queue, Market Orders, Transactions or Notifications (may we have the text snippets for this one? As part of the dump or as additional fields. The current output can only be used in a meaningful way if you do a lot of research and trial 'n' error).

Also the char sheet would be helpful as it is often used for checking characters after their application.

My priority request would be as others have suggested getting all the previous functionality running on CREST. I really don't want to have to maintain both authentication methods. I would much rather being able to just switch everything over to CREST and then grow to new things once that is done.