I’m just starting to look into the possibilities of the API, but I’m not entirely sure where to begin.
Basically, I’m trying to figure out if it’s possible to retrieve simple data by using purely Javascript on a web page, or whether I’d actually need to learn php/c/java to do that.
By simple data, I mean an event state, or an item’s recipe info etc.
It should be posible. I didn’t look it true the whole appi. But basically if you can get the data in the for of txt or some other common format java can read and show it. Besides php isn’t that different from java anyway in term of sintaxes. And i think that this api was written in json. Java sript object notation
As they said javascript is enough to use the API but keep in mind that if you app has more than one user, you wont be able to cache the api result.
To do some caching you’ll need so server side code (ie: php)
The api returns a json object which can be read and used by JavaScript.
Samples have been provided in some of the above posts.
@Ice of Dragons: Java script has nothing to do with Java except that one part of the name. It is is totally different Programming language.
Furthermore the back-end part of the API is probably written in one of ASP.NETs programming languages as the backend server is an IIS with version 7.5
The api returns a json object which can be read and used by JavaScript.
Samples have been provided in some of the above posts.
@Ice of Dragons: Java script has nothing to do with Java except that one part of the name. It is is totally different Programming language.
Furthermore the back-end part of the API is probably written in one of ASP.NETs programming languages as the backend server is an IIS with version 7.5
Just for clarification: According to the headers, the forums are coded in Ruby, using the Ruby on Rails framework. Not to mention there have occasionally been Rails errors popping up back in the day, and the X-Powered-By header shows it uses Phusion Passenger (and there’s a reference to mod_rails). That being said, the server does appear to be Microsoft’s IIS 7.5, which is an odd choice for RoR (Truth be told, I didn’t even know IIS+Passenger was possible; the preferred choice is Nginx/Apache+Passenger).
Back on topic: While I am busy, creating a node.js library for GW2’s API is on my to-do list.
Also…
As they said javascript is enough to use the API but keep in mind that if you app has more than one user, you wont be able to cache the api result.
To do some caching you’ll need so server side code (ie: php)
Listen to this person. While I have no issue with people testing JS client side scripts, I discourage anyone from releasing anything wherein the client-side directly accesses GW2’s API. If it’s not cached and accessed every single time a user opens the page, you’re sending in far more requests than necessary. This is something where, if too many people don’t optimize their applications, we may start seeing API rate limitations.
As they said javascript is enough to use the API but keep in mind that if you app has more than one user, you wont be able to cache the api result.
To do some caching you’ll need so server side code (ie: php)
Listen to this person. While I have no issue with people testing JS client side scripts, I discourage anyone from releasing anything wherein the client-side directly accesses GW2’s API. If it’s not cached and accessed every single time a user opens the page, you’re sending in far more requests than necessary. This is something where, if too many people don’t optimize their applications, we may start seeing API rate limitations.
Does that mean that Anet may start restricting the amount of data we can ask for because the bandwidth cost will become too high?
So basically what you suggest is to create a self-updating copy of the entire GW2 info on your own server with php, and make people use that?
That being said, the server does appear to be Microsoft’s IIS 7.5, which is an odd choice for RoR (Truth be told, I didn’t even know IIS+Passenger was possible; the preferred choice is Nginx/Apache+Passenger).
I believe the IIS is just a proxy – the application server may be a completely different
Listen to this person. While I have no issue with people testing JS client side scripts, I discourage anyone from releasing anything wherein the client-side directly accesses GW2’s API. If it’s not cached and accessed every single time a user opens the page, you’re sending in far more requests than necessary. This is something where, if too many people don’t optimize their applications, we may start seeing API rate limitations.
The problem with caching is that you have to decide how often to refresh your data. For certain data like the items data from this api, it makes sense to cache because they hardly change. For others like the TP data, they change often and most users would rather not make huge investment decisions based on outdated data.
It is also possible to cache your data through a standalone windows app without a database. My TP app minimizes to a system tray icon and runs in the background, refreshing its data at certain time interval with a refresh data command option for the user if he so chooses.
As long as the script/app writer keeps in mind to minimize network bandwidth, it should generally be good enough. That said, I think most of the bandwidth problems would come from non-technical users who use Excel to auto refresh their spreadsheet data too often without being aware of bandwidth issues.
Listen to this person. While I have no issue with people testing JS client side scripts, I discourage anyone from releasing anything wherein the client-side directly accesses GW2’s API. If it’s not cached and accessed every single time a user opens the page, you’re sending in far more requests than necessary. This is something where, if too many people don’t optimize their applications, we may start seeing API rate limitations.
The problem with caching is that you have to decide how often to refresh your data. For certain data like the items data from this api, it makes sense to cache because they hardly change. For others like the TP data, they change often and most users would rather not make huge investment decisions based on outdated data.
It is also possible to cache your data through a standalone windows app without a database. My TP app minimizes to a system tray icon and runs in the background, refreshing its data at certain time interval.
As long as the script/app writer keeps in mind to minimize network bandwidth, it should generally be good enough. That said, I think most of the bandwidth problems would come from non-technical users who use Excel to auto refresh their spreadsheet data too often without being aware of bandwidth issues.
You make good points, but in general, unless you never expect to have a sizable user base, it is best to make a single call to the API and cache that, even if you call and re-cache it every minute, rather than making a unique call for each user.
You make good points, but in general, unless you never expect to have a sizable user base, it is best to make a single call to the API and cache that, even if you call and re-cache it every minute, rather than making a unique call for each user.
I’m too lazy to start up my Visual Studio environment (it’s installed on my laptop while I’m working now on my PC), so, I decided to create an event page using pure javascript. I won’t release it (I would have to clean up my code and that sounds too much like work and I do that enough during working hours!), so don’t worry about that.
But even with the events, you can cache a lot. I simply saved the result of the event names, world names and map names API’s in a JSON file and load those using JQuery. Only when I want an updated status report, will I go to the server. I only make one call (events.json), getting everything I want for the map or the world (depending if I selected a specific map or not).
I only may need to update those three cached versions every time there’s a major update…
You make good points, but in general, unless you never expect to have a sizable user base, it is best to make a single call to the API and cache that, even if you call and re-cache it every minute, rather than making a unique call for each user.
I’m too lazy to start up my Visual Studio environment (it’s installed on my laptop while I’m working now on my PC), so, I decided to create an event page using pure javascript. I won’t release it (I would have to clean up my code and that sounds too much like work and I do that enough during working hours!), so don’t worry about that.
But even with the events, you can cache a lot. I simply saved the result of the event names, world names and map names API’s in a JSON file and load those using JQuery. Only when I want an updated status report, will I go to the server. I only make one call (events.json), getting everything I want for the map or the world (depending if I selected a specific map or not).
I only may need to update those three cached versions every time there’s a major update…
That sounds reasonable and that is what Zicore and I currently do with the items and recipes JSON data from gw2db. This is why I would suggest that ArenaNet makes it possible to grab all the items details in 1 call so that it is easier for us to cache it.
As for the world names, map names, etc. they hardly change so it makes sense for you to cache them too. On the other hand, I doubt those calls take up much of their server resources either compared to events.json.
I also doubt the events requests take up much resources either. I’d guess they’re writing data to memcache-like cache on update, then just pull from there.
I also doubt the events requests take up much resources either. I’d guess they’re writing data to memcache-like cache on update, then just pull from there.
Even less for map names and world names.
If ArenaNet really wants to save their server bandwidth resources, they should make it easier for us to cache their items and recipes data in 1 call, rather than requiring us to fetch them one at a time. Those kinds of saving would be more significant.
With properly cached responses JavaScript is fine, you just have to set the “If-Modified-Since” header to avoid the round-trip.
ArenaNet doesn’t cache the JSON response though.
> Cache-Control:no-cache
Yeah, maybe we can set longer cache periods for more static content like the event names or item ids. I started by playing it safe, since I’ve been seeing sporadic reports of events being out-of-date and I suspect that this might be one of the causes.
