EVE Search - Some questions in prep for the CREST beta for developers

Check My IP Information

All Channels

EVE Technology Lab

Some questions in prep for the CREST beta for developers

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: 1 2 :: [one page]

Author	Thread Statistics \| Show CCP posts - 4 post(s)

CCP Seagull C C P C C P Alliance 13	Posted - 2012.05.14 17:48:00 - [1] - Quote 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. Technical Producer CCP Games Reykjavik

Kronus Heilgar Caldari Provisions Caldari State 6	Posted - 2012.05.14 17:55:00 - [2] - Quote Good questions. I think that access-by-request would work well. The other option might be to temporarily set it up for Singularity data only (like you did when testing the CAK system). To deal with the many authentication methods, my first thought would be to finally put an end to the old Limited/Full API keys (all developers have had nearly a year now to modify their apps, and since you can't create new ones anyways they're probably used very little now). That alone would reduce the confusion by 33%. This is not the signature you're looking for.
Captain Thunk Sniggerdly Pandemic Legion 76	Posted - 2012.05.14 17:56:00 - [3] - Quote 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.
Dern Morrow Vanguard Frontiers Intrepid Crossing 0	Posted - 2012.05.14 17:59:00 - [4] - Quote Re #1) honestly, if it's just the contact list updating that is mentioned in the link you gave, then I don't have much reason to play around with CREST right now. At best, I could make some sort of "go to this web site and we will automatically add all of the PL supercap pilots to your address book!" system, but nobody will want to give me write access to their account for this, so the implementation isn't very worth it. Possibly I could build an alliance standings management application so that people who are in High Command of IRC, but not necessarily directors of the executor corporation, can affect alliance standings. But I'm not even sure if I can do that with CREST, because I'm not directly familiar with how alliance standings are drawn. For #2) It has been long enough that you are justified in killing off the original API keys, IMO. There will naturally be some unrest but I don't think it will be too bad. :-) For CREST's permissions, honestly I would have suggested you go with something like OAuth. It's already a well established protocol and users are familiar with it. "I went to foo.com and then they sent me to eveonline.com to grant access." It's the same sort of thing as "this web site is requesting access to my Facebook account" and given Facebook's ubiquity, you'd be well placed to capitalize on that user knowledge. Granted, the advantage to API keys is that you can cut and paste them, which OAuth doesn't really handle as it is built for a web environment. This is an argument for maintaining the "API Keys" system + allow OAuth, so that people can do one or the other depending on what they need... Anyway. Some thoughts.

CCP Seagull C C P C C P Alliance 13	Posted - 2012.05.14 18:07:00 - [5] - Quote Dern Morrow wrote: Re #1) honestly, if it's just the contact list updating that is mentioned in the link you gave, then I don't have much reason to play around with CREST right now. 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. :) Dern Morrow wrote: R For CREST's permissions, honestly I would have suggested you go with something like OAuth. CREST is using oAuth. http://wiki.eveonline.com/en/wiki/CREST_Documentation#Authorization Technical Producer CCP Games Reykjavik

Dern Morrow Vanguard Frontiers Intrepid Crossing 0	Posted - 2012.05.14 18:20:00 - [6] - Quote CCP Seagull wrote: 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. :) Roger that. If you can ever do some Industry stuff with CREST though, I will be your ... uh, you can flog me to test it hard. My corporation handles much of the logistics (including production) for IRC and it's very effort intensive. CCP Seagull wrote: CREST is using oAuth. http://wiki.eveonline.com/en/wiki/CREST_Documentation#Authorization Nooooooooo~~ reading comprehension fail! My bad. Thanks. :)
Shellac Brookdale RAZOR Alliance 5	Posted - 2012.05.14 21:01:00 - [7] - Quote 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.
Trenker 18	Posted - 2012.05.15 11:29:00 - [8] - Quote CCP Seagull wrote: 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 YEEESSS ... I'm getting a geek boner. That's the coolest thing I've seen since node.js. CCP Seagull wrote: 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? List of user accounts should work fine. Only problem I can see: People who are not a director of a corp / alliance (like me) may cannot use and test the full feature set. So how about providing some dummy characters inside a dummy corp? CCP Seagull wrote: 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. How about combining the generation of API keys with OAuth. An Auth request could (optionally) include the request for an API key with a given bitmask. If the user grants access to the app, this key is accessible via a GET, or directly as parameter in the return URL.
Peter Powers Terrorists of Dimensions Electric Monkey Overlords 80	Posted - 2012.05.15 11:38:00 - [9] - Quote CCP Seagull wrote: 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? 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) CCP Seagull wrote: 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. 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
Dragonaire Corax. The Big Dirty 41	Posted - 2012.05.17 04:44:00 - [10] - Quote I think for the initial testing us suppling you with a list of user accounts is probably the best/easiest for everyone. I know personally I would probably only be using 2-3 for anything I'll be doing with the limit stuff that will be available to us at this point. Best thing for all the key stuff would be to drop the legacy keys as even most of the older third party projects that had been dropped by the original developers have been brought back to life by someone else and updated them to work with CAKs. I would put out with the next big release to everyone that the legacy keys will be turned off in like 3 month from that time to give the last couple of hold outs time to do what the rest of us did months ago and switch over. I don't know if anyone at CCP has looked at how many requests with old keys you still get but I would think by this time the numbers should be pretty low. I'd say if less then 10% are from the old keys it's time to pull the plug on them as that will be the only way people will stop using them and update. On having both Crest with OAuth and current API data and keys in the same application/libraries I think it will be done for a while anyway until Crest is able to cover at least 75% of the same data as is available from the current APIs then we'll see things moving over to pure Crest. Only reason it would take longer is if some of the more important stuff is left until last to be done and then the CCP developers will get to hear from the third party developers a lot in that case Finds camping stations from the inside much easier. Designer of Yapeal for Eve API. Check out the Yapeal PHP API library thread for more information.

Two step Aperture Harmonics K162 1937	Posted - 2012.05.18 04:42:00 - [11] - Quote 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. CSM 7 Secretary CSM 6 Alternate Delegate @two_step_eve on Twitter My Blog

CCP Nullarbor C C P C C P Alliance 364	Posted - 2012.05.22 22:02:00 - [12] - Quote I want to bump this thread with another question, from the current API what would be your priority order for porting them over to CREST? In particular highlight any where having read capability for data already exposed might be super beneficial. CCP Nullarbor \| Exotic Dancer

Splodger Ausbruch 24	Posted - 2012.05.22 22:33:00 - [13] - Quote 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.
Marcel Devereux Aideron Robotics 108	Posted - 2012.05.23 01:17:00 - [14] - Quote #1 Beta is meant for public consumption but with the understanding that things can and will change. Is it enough to just limit the developers that have access rather than their users? I am willing to suffer through any API changes on your side as long as we get a heads up about the changes. #2 and #3 Most of us have already required our users to move to the new customizable API keys. What would be awesome if we could just move our users over CREST auth and away from API keys. If you can provide a bridge between for the old API through CREST then we could switch over fully to using CREST.
Trenker 18	Posted - 2012.05.23 17:37:00 - [15] - Quote CCP Nullarbor wrote: I want to bump this thread with another question, from the current API what would be your priority order for porting them over to CREST? In particular highlight any where having read capability for data already exposed might be super beneficial. 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.
Sakari Orisi The Dark Space Initiative 18	Posted - 2012.05.23 17:46:00 - [16] - Quote CCP Nullarbor wrote: I want to bump this thread with another question, from the current API what would be your priority order for porting them over to CREST? In particular highlight any where having read capability for data already exposed might be super beneficial. Things that'd allow me to build stuff without having to use the old API at all, it'd be the only reason for me to start porting.I don't want to maintain access to two different systems. Basics like character sheet, are obviously on top of this list. Things like the skills the character has are also pretty interesting as a lot of stuff can be done with it. other than that, I guess I'd port the APIs over that have the biggest amount of hits at this moment on the old API ?
ShadowMaster 41	Posted - 2012.05.23 23:23:00 - [17] - Quote CCP Nullarbor wrote: I want to bump this thread with another question, from the current API what would be your priority order for porting them over to CREST? In particular highlight any where having read capability for data already exposed might be super beneficial. 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.
Peter Powers Terrorists of Dimensions Electric Monkey Overlords 81	Posted - 2012.05.24 14:45:00 - [18] - Quote CCP Nullarbor wrote: I want to bump this thread with another question, from the current API what would be your priority order for porting them over to CREST? In particular highlight any where having read capability for data already exposed might be super beneficial. most api pages are only relevant in package with a few others. the priority put on 'em also depends alot on the usecase. i'll see if i can compile you such list by my usecases during the weekend, but this will mostly benefit a special subgroup of devs and not everyone, since for example i wont care about factional warfare stuff, however someone doing that would probably put those pages on top of the list.
Desmont McCallock 176	Posted - 2012.05.24 14:54:00 - [19] - Quote CCP Nullarbor wrote: I want to bump this thread with another question, from the current API what would be your priority order for porting them over to CREST? In particular highlight any where having read capability for data already exposed might be super beneficial. CharacterSheet SkillQueue MarketOrders IndustryJobs WalletJournal WalletTransactions EverythingElse
Tonto Auri Vhero' Multipurpose Corp 23	Posted - 2012.05.24 18:19:00 - [20] - Quote Desmont McCallock wrote: CCP Nullarbor wrote: I want to bump this thread with another question, from the current API what would be your priority order for porting them over to CREST? In particular highlight any where having read capability for data already exposed might be super beneficial. CharacterSheet SkillQueue MarketOrders IndustryJobs WalletJournal WalletTransactions EverythingElse I'd stick Notifications before IndustryJobs. Other than that, the list looks right.

Verite Rendition F.R.E.E. Explorer EVE Animal Control 116	Posted - 2012.05.25 12:17:00 - [21] - Quote CCP Nullarbor wrote: I want to bump this thread with another question, from the current API what would be your priority order for porting them over to CREST? In particular highlight any where having read capability for data already exposed might be super beneficial. If it means you'll further iterate on them, all of the Map calls would be nice. There's a lot of map data that isn't exposed in the current API that is in the in-game map, such as the various system development indexes. Working those into Sovereignty.xml would be fantastic.
Etil DeLaFuente New Eclipse Initiative Mercenaries 8	Posted - 2012.05.27 09:49:00 - [22] - Quote CREST new API looks very interesting when you need to update your ingame data from a website or other third party tool. The contact list is a good example. Buy/sell orders could be another one, skill queue, etc.. Will CREST for readonly data need OAuth aswell ? If so, how should a third party handle the authentication ? Do you need to store something ? Will your account related info be highly exposed ? For instance, when i need a character informations, i'll just call the actual API without any sort of authentication, what would be the behavior using CREST ?
Etil DeLaFuente New Eclipse Initiative Mercenaries 9	Posted - 2012.05.30 05:54:00 - [23] - Quote Bump, because i'd really like to have an answer :)
Tonto Auri Vhero' Multipurpose Corp 24	Posted - 2012.05.30 08:28:00 - [24] - Quote Etil DeLaFuente wrote: CREST new API looks very interesting when you need to update your ingame data from a website or other third party tool. The contact list is a good example. Buy/sell orders could be another one, skill queue, etc.. Will CREST for readonly data need OAuth aswell ? If so, how should a third party handle the authentication ? Do you need to store something ? Will your account related info be highly exposed ? For instance, when i need a character informations, i'll just call the actual API without any sort of authentication, what would be the behavior using CREST ? Naive you. Do you seriously think that it'll have write capability? Doubt it'll any different from current API implementation.
Mikokoel Mining Industry Exile Foundation Eternal Evocations 1	Posted - 2012.05.30 14:39:00 - [25] - Quote Tonto Auri wrote: Naive you. Do you seriously think that it'll have write capability? Doubt it'll any different from current API implementation. have you watched the devtrack sessions at Fanfest? If that what he did with the contacts wasn't write access, there was some serious magic involved. Write-Access is the whole point of the new API EvE API Development zap - advanced programming
Etil DeLaFuente New Eclipse Initiative Mercenaries 9	Posted - 2012.05.31 06:45:00 - [26] - Quote Tonto Auri wrote: Etil DeLaFuente wrote: CREST new API looks very interesting when you need to update your ingame data from a website or other third party tool. The contact list is a good example. Buy/sell orders could be another one, skill queue, etc.. Will CREST for readonly data need OAuth aswell ? If so, how should a third party handle the authentication ? Do you need to store something ? Will your account related info be highly exposed ? For instance, when i need a character informations, i'll just call the actual API without any sort of authentication, what would be the behavior using CREST ? Naive you. Do you seriously think that it'll have write capability? Doubt it'll any different from current API implementation. http://wiki.eveonline.com/en/wiki/CREST_Documentation
Bai Guang Root. 0	Posted - 2012.06.04 05:37:00 - [27] - Quote 1) Either link it to Sisi to start for the beta or have the per account lock on the API's so that only registered developers would have access. Either option i think would Suffice 2) Phase out the legacy API. I realize that the single key is better for some things, but the vast majority of the developers have incorporated the new key system. 3) Anything related to the wallet would get my vote. Would love write access to it as well, to be able to send people isk while not being in game per say (think mobile apps, etc).
Perduim Oneraria EvE Finance 0	Posted - 2012.06.21 22:12:00 - [28] - Quote Any news on when we can start playing around with CREST? The initial login on https://chaoslogin.testeveonline.com/Account/Challenge already works accept: Login was unsuccessful. Please correct the errors and try again. The character challenge failed
Etil DeLaFuente New Eclipse Initiative Mercenaries 9	Posted - 2012.06.22 22:50:00 - [29] - Quote And i'm still waiting for an answer, like for almost a month now

CCP Seagull C C P C C P Alliance 13	Posted - 2012.06.28 11:34:00 - [30] - Quote Etil DeLaFuente wrote: CREST new API looks very interesting when you need to update your ingame data from a website or other third party tool. The contact list is a good example. Buy/sell orders could be another one, skill queue, etc.. Will CREST for readonly data need OAuth aswell ? If so, how should a third party handle the authentication ? Do you need to store something ? Will your account related info be highly exposed ? For instance, when i need a character informations, i'll just call the actual API without any sort of authentication, what would be the behavior using CREST ? Sorry for the delay in answers here, we've been very very busy. There will be endpoints for a bunch of public read-only stuff, that require no authentication. Things like starmap data, basic character and corp info and such, item info and so on. Technical Producer CCP Games Reykjavik


Etil DeLaFuente New Eclipse Initiative Mercenaries 9	Posted - 2012.06.30 09:08:00 - [31] - Quote Thanks, now work harder and give us the damn thing :D


Pages: 1 2 :: [one page]

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.