EVE Technology Lab

 
  • Topic is locked indefinitely.
3 Pages123Next page
 

XML API (angry thoughts)

First post
Author
Gallente Federation
#1 - 2017-01-10 00:49:50 UTC  |  Edited by: Jone Sad
Simple question - is it gonna to die in next year\two? Don't want to spent time if it will be deprecated in a year.

And where is full description of it? A lot of changes were done i've use it before.

PS: Is there any another alternative except 'access token'? Access tokens (i means requests with headers the worst solution in internet ever) not best solution same as oauth for eve. =\
Vote Steve Ronuken for CSM
#2 - 2017-01-10 03:02:47 UTC
Jone Sad wrote:
Simple question - is it gonna to die in next year\two? Don't want to spent time if it will be deprecated in a year.

And where is full description of it? A lot of changes were done i've use it before.

PS: Is there any another alternative except 'access token'? Access tokens (i means requests with headers the worst solution in internet ever) not best solution same as oauth for eve. =\



Yes, it's going to die within the next 16 months or so.


No, it's not going to change from using oauth. So that's access tokens, and refresh tokens to create them at will.

Bear in mind, it's pretty much the same as the vcode and key.

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter

Gallente Federation
#3 - 2017-01-10 10:38:28 UTC
It's bad, ccp killing simple "play" with api. This oauth really annoying thing...
Gallente Federation
#4 - 2017-01-10 10:41:26 UTC  |  Edited by: Jone Sad
But hey, does the crest or sso cover all xml api? Cannot find how to get using it corp data. Where is description?

Added:
Or ccp only changed using "keyID \ vCode" to "accessToken"? All calls stay same? Changed only var in url (call)?
#5 - 2017-01-10 12:51:23 UTC
No, CREST/ESI do not cover all of the XML API. But they cover a lot of it.

The calls are completely different. (The format is JSON rather than XML, for example).

Trade Hub Price Checker: stop.hammerti.me.uk/pricecheck

Visit "Haulers Channel" in game for all matters courier-related.

Structure name/system API: stop.hammerti.me.uk/api

Gallente Federation
#6 - 2017-01-10 13:08:48 UTC
Messenger Of Truth wrote:
No, CREST/ESI do not cover all of the XML API. But they cover a lot of it.

The calls are completely different. (The format is JSON rather than XML, for example).


If they don't - it's useless at all. That crest/esi is useless, hate already it. =\

Really? Common man, there is no difference at all, json or xml.... But realization of that oauth and xml api (simple get) - role.

By api you could do everything, simple and quick. Now about 80% all already written eve-api software will be disabled because "omg wtf is this, how can i retrieve simple data?".

In next year (if ccp will disable its xml api) only developers (I mean real developers) can use their "smart" api... And without real money as payment yeah? That means that all community will do software only for themself in private repositories and if they have such developer. who will spent his time, not payed time.

GOOD LUCK CCP, YOU DO THE SAME AS ALWAYS, BROKING...

PS: You spent SOOOOOOOOOOOOOO many time to create new oauth and api but... Did you count queries required now for any data call? Hello access tokens.... What next? Payed limit for queries? AHAHAHAHAH...
#7 - 2017-01-10 14:22:28 UTC
Someone is butt hurt.
Gallente Federation
#8 - 2017-01-10 14:46:19 UTC
Blacksmoke16 wrote:
Someone is butt hurt.

Yep, because every monkey want "social login" (oauth) on its site, but don't know how developers suffer about it. =\
#9 - 2017-01-10 15:00:29 UTC  |  Edited by: Blacksmoke16
Personally, yes it is a bit more in dept than just doing a GET request to an endpoint to get data.

BUT, being able to use tokens for the XML API, being able to open windows using ESI and being able to do things that developers could only dream of with only the XML makes it all worth it.

The convenience of just having people log in like they would into the game and boom have data is much better than having to make an API key, give it to someone and manage all of them.

In addition, dealing with JSON from the ESI/CREST endpoints are much easier to work with than the XML API. XML API by industry standards itself is pretty old. You can read up more on why they decided to do it here: https://community.eveonline.com/news/dev-blogs/introducing-esi/

Personally you are the only one that is against the OAuth that i have come across.
Gallente Federation
#10 - 2017-01-10 16:20:06 UTC
Blacksmoke16 wrote:
Personally, yes it is a bit more in dept than just doing a GET request to an endpoint to get data.

BUT, being able to use tokens for the XML API, being able to open windows using ESI and being able to do things that developers could only dream of with only the XML makes it all worth it.

The convenience of just having people log in like they would into the game and boom have data is much better than having to make an API key, give it to someone and manage all of them.

In addition, dealing with JSON from the ESI/CREST endpoints are much easier to work with than the XML API. XML API by industry standards itself is pretty old. You can read up more on why they decided to do it here: https://community.eveonline.com/news/dev-blogs/introducing-esi/

Personally you are the only one that is against the OAuth that i have come across.


XML is only file format. So as I said there is no real point between xml\json even txt... I don't think you do realize it. So oauth and json is not connected. XML api can be changed EASILY to json if ccp will want. It's only output data. Ok? Ok...

You are saying that CREST is good, ok, what it can, that i cannot do using xml api? What this crest adds to api? Nothing, it return same data but now in another (harder) way.

Next one, for those who is not understand - SSO is way to get keyID\vCode simplier. So if you use it now - you will not ask members of your corp create new api, it would be enought ask them login. Nothing new! You realize it? Is it easier? For member - yes, but what about developer? Now you use accessToken against keyID\vCode. But now this accessToken should be obtain in hard way (hello oauth).

ESI or what ever... Same! Same data as prev. xml api, no? New Features? For whom? As I said, old XML api gives us everything player\developer need in easy way. Now, developer need create sites with authenticatoin + oauth (what for!?!) to get some data. And i won't say about refresh token call count.

So, to clearfy this. What this new CREST and ESI can? For what it was created, can someone describe? With real examples, not just "it's cooler"... =\
#11 - 2017-01-10 20:49:41 UTC  |  Edited by: Blacksmoke16
ESI/CREST allows you to:

Arrow Open windows within the client from your app
Arrow Save/read fittings from your app
Arrow Invite people, add wings, kick people, read fleet data etc from your app
Arrow Add/edit contacts from your app
Arrow Update the vulnerability times on structures from your app
Arrow Create/delete mail labels and send/edit/delete mails from your app
Arrow Set/change destination from your app
Arrow Update calendar events from your app
Arrow Read current location/ship in nearly real time from your app

Plus whatever will be added in the future.

So please tell me how I can do this stuff with the XML API.
Vote Steve Ronuken for CSM
#12 - 2017-01-10 22:52:32 UTC
Blacksmoke16 wrote:
ESI/CREST allows you to:

Arrow Open windows within the client from your app
Arrow Save/read fittings from your app
Arrow Invite people, add wings, kick people, read fleet data etc from your app
Arrow Add/edit contacts from your app
Arrow Update the vulnerability times on structures from your app
Arrow Create/delete mail labels and send/edit/delete mails from your app
Arrow Set/change destination from your app
Arrow Update calendar events from your app
Arrow Read current location/ship in nearly real time from your app

Plus whatever will be added in the future.

So please tell me how I can do this stuff with the XML API.



ding ding ding, we have a winner.

CREST interacts with Eve at the same level as the client/ the XML api is a nasty behind the scenes hack which interacts with the database directly, so can't touch game state. It's also read only, where as CREST is read/write

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter

DARKNESS.
#13 - 2017-01-11 05:49:58 UTC
Is there a matrix or something along those lines that shows developers where the parity short falls are with Swagger/CREST are to help guide traffic towards the "new" way.

Also does this mean the whole Key/ValidationCode system is redundant going forward completely?
#14 - 2017-01-11 06:45:02 UTC
I know the original API is going, and Im fine with that... I just need to learn some things I didnt know before and I'm all for that... This is just a game, but the stuff I learn while writing things for that game can be carried into rl so yeah Im fine with the changes.

However my question is this... ppl are talking about the API going, which I get but on the other side they are talking about converting to Crest/ESI as in both are staying

Correct me if Im wrong but arent the original API, Crest, and Swagger all separate entities? And didn't they say they were eliminating all but swagger?

I only ask cause I'll use CREST some more if its staying around but I have been trying to stick to just the new stuff on the assumption that the other 2 were going to be eliminated

Thanks
Frozen Dawn Alliance
#15 - 2017-01-11 07:33:08 UTC
Personally I see nothing bad with the current xml API.

It serves a different purpose. No reason to remove the API unless it causes some really strong technical challenges in CCP side.
Vote Steve Ronuken for CSM
#16 - 2017-01-11 13:14:52 UTC  |  Edited by: Steve Ronuken
Japetus wrote:
I know the original API is going, and Im fine with that... I just need to learn some things I didnt know before and I'm all for that... This is just a game, but the stuff I learn while writing things for that game can be carried into rl so yeah Im fine with the changes.

However my question is this... ppl are talking about the API going, which I get but on the other side they are talking about converting to Crest/ESI as in both are staying

Correct me if Im wrong but arent the original API, Crest, and Swagger all separate entities? And didn't they say they were eliminating all but swagger?

I only ask cause I'll use CREST some more if its staying around but I have been trying to stick to just the new stuff on the assumption that the other 2 were going to be eliminated

Thanks



You're correct. The final goal is just ESI, not CREST or the XML API.

There's some structural issues with the latter two, which are being eliminated with ESI.

(However, bear in mind that the goal date for elimination is 15 months away or so. And there won't be feature parity until closer to that date)

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter

Gallente Federation
#17 - 2017-01-11 17:25:20 UTC
More uncomplete apis! CCP have only one hired developer for API? LOL

CCP killing desire to use their apis... New means good? Don't think so...

At this moment we have x3 apis (methodic)? Am I wrong? So flexible, but what for!?!?! There is no total\full working manuals for them. Only links for official methods how should it work in internet (hello oauth)..

And ppl should "learn more", nice, rly... And what about that who don't want? Yes - he won't use your api. XML API was simple - even in simple script anyone could receive data. Common, he even can ask friends do this one (who not playing eve) because it was easy. But now... You ask then create real software for free....

Best move ever. XD

Sad one that you cannot stop! There was xml api and it was (and still) good. Then came crest... Then came sso... Now coming ESI. Common! Stop this! When will be a point with "all works and have full manual"? My children has grew up and you cannot do your job. You know what is deadline? XD And you ask use latest... Never - latest is not good, latest means - uncomplete.
The-Culture
#18 - 2017-01-11 18:12:20 UTC
Zad Murrard wrote:
Personally I see nothing bad with the current xml API.

It serves a different purpose. No reason to remove the API unless it causes some really strong technical challenges in CCP side.



This... API is a reliable proven system for getting information in an easy manner. Yes ESI/CREST have some cool PUT abilities but the majority of developers are just looking for info not trying to make your map pop up and flash dickbutt patterns at you.
DARKNESS.
#19 - 2017-01-12 02:16:57 UTC

  • Industry, in general, is moving towards Swagger because of its self-documenting approach.

  • Any time you depend on a 3rd party for your API needs, you always bake in assumption fails. Whether it be verbs in the endpoints or data coming back, you always layer in abstraction to self-guard your domain. For example, CCP uses "int" for their ID system, whereas I use GUIDs ..I absorb the int and catch it but in my own relational model, I rely on my own.

  • CCP need to learn how to finish what they start, maybe the ESI is the answer to that but from what I've seen so far its "shiny object syndrome" development.

  • I'm fine with the deprecation of code, provided you can establish a map out of where we are today to where will be tomorrow. Alongside some healthy actual roadmap.

  • The implementation of Swagger at the moment relies heavily on multiple "_" to break up the verb(s). In most tooling right now with swagger they typically prefer it to be verb_action (one) so already they're likely to run up against code-gen tooling etc.

  • Single Sign On is unnecessary. There is again no point to linking a user(s) actual in-game credentials to 3rd party app development. It encourages security failing(s) for one and it's like asking for your driver's license to buy a carton of milk. The Key/AuthCode approach was actually more realistic and encourages the end-users to monitor their allocation of data to 3rd party apps in a centralised fashion (constancy and consistency in one with an emphasis on strengthening behaviour not weakening it - as the user continues to approve/reject in the one spot. SSO fragments the user's cognitive intelligence by requiring them to take a position without context to other applications - moreover - you can also encourage the user to compartmentalise their authority groupings by letting them define their own taxonomy). SSO also is harder for developer(s) to utilise outside a web-only solution than a simple credential based one found in the current XML way.
#20 - 2017-01-13 14:07:54 UTC
I am cool with the idea of the new codes although it would be nice if they kept the old simple API keys for the newbs like me who can only just scrape by with the little code we know.

I just spent a week building my self a vary good looking fully detailed site that runs off just API grabs and now I hear they are going to change how we get the info. Makes me wish I didn't wast my time with any of it.

C.orporate
C.ontrol
P.ointing

E.veryone's
V.ision
E.lsewhere

Fly Safe everyone o7
3 Pages123Next page
Forum Jump