Walalla Trade Route
  2146 active members
  189 are online







Message CenterRPG CenterQuestion Center
Archives » Api call with jquery not working
Hey devs,

Since it's been almost a month since Selatos has been available to grant me access to the web service forums, I figure I'll just ask here.

I see that some of the endpoints do not require authentication, so I was playing around trying to hit them. I'm doing a jquery call like this (sorry for the formatting, is there a bbCode for code snippets?):

var url = 'https://www.swcombine.com/ws/v1.0/api/time/cgt/';

url: url,
method: 'GET',
dataType: 'json',
contentType: "application/json; charset=utf-8",
success: function(response) {
error: function (err) {

That request spins for a long time 30+ seconds and then fails without any response or error.

I did change the url from http to https because most of the websites I was trying from (just in the browser console) are ssl and were throwing mixed mode blocking errors. Does the url not work for https, or am I missing something else in the call?

I would appreciate if someone could just drop in an example javascript call that works for them. Thanks!

Ah, it must be that ssl is not supported on the combine's end. Because using this this, https://www.hurl.it/, I can make a GET to http://www.swcombine.com/ws/v1.0/api/time/cgt/ and get a response. But to https://www.swcombine.com/ws/v1.0/api/time/cgt/ times out.


So, http configuration isn't my strong suit and this may be much more effort than I understand, but it seems to me that securing the combine's web service behind https would be beneficial for client-side applications.

As it is I can't simply call the service from a https web application. I will need to create an http proxy in my node service to make those unsecure calls.


Year 17 Day 287 11:38
you don't really need to create an http proxy in your node service. You just need to create a wrapper for the Combine API using CURL to send the requests to the API. There's no real need for a proxy in that situation.

As well, I don't think it's intended use to call Combine's WS using jQuery since most calls require a secret key to function. As well, eventually the API might end up being rate limited. You're supposed to make a request, cache the data for a while, then make a new request when you need new data or want to get a fresh set of data. All of these things can easily be done on your server side. That's the intended API functionality.

Since you should be wrapping your calls through your server itself, Combine doesn't really *need* to enable HTTPS for the WS.

Edit: I'd also like to say that Combine provides you with our Unix time offset so you don't even need to call our server to get the current Combine time. All you need to do is get your current Unix timestamp, subtract our offset, then do some maths to get the second, minute, hour, day, and year. From there, you can easily manipulate the date yourself and automatically increment it.

Edit 2: To give you some help with calculating it yourself, you should do the following (pseudocode!):

timestamp = unixTimestamp - 912668400
seconds = timestamp % 60
minutes = floor(timestamp / 60) % 60
hours = floor(floor(timestamp / 60) / 60) % 24
days = (floor(floor(floor(timestamp / 60) / 60) / 24) % 365) + 1 //We add 1 because we now start the year off on Day 1 instead of Day 0. This accounts for that
years = floor(floor(floor(floor(timestamp / 60) / 60) / 24) / 365)

Alternative (that requires less floors and I'd imagine would be faster because multiplication is faster than division):

timestamp = unixTimestamp - 912668400
seconds = timestamp % 60
minutes = floor(timestamp / 60) % 60
hours = floor(timestamp / (60 * 60)) % 24
days = (floor(timestamp / (60 * 60 * 24)) % 365) + 1 //We add 1 because we now start the year off on Day 1 instead of Day 0. This accounts for that
years = floor(timestamp / (60 * 60 * 24 * 365))

Edited By: Ulrike Rayne Schultheiss on Year 17 Day 287 12:28
Year 17 Day 287 12:40
Heya, thanks for the guidance. However, the Combine provides a client-side application - which by definition means non-server side, so that was why I was asking.

Using Oauth with angular's $http service is pretty standard for interacting with RESTful interfaces (providing the token as the key to authenticate and get data). I've set this up a couple times at my work. The xml webpage at (http://www.swcombine.com/ws/v1.0/ - all the documentation I can find, doesn't look strictly RESTful, but it returns data just the same from my testing.

Operating within rate limits is fine for me, as I'll be caching data in sessionStorage. In fact, I'll be writing some data back to another db like Firebase and make subsequent GETs from there. I'm not really sure what the rate limits are, as the response from that call didn't provide much detail. Maybe I just missed it.

The http proxy isn't that difficult, and I'm setting it up now. Just saying that web services for client-side app development usually mean that "clients" can call your services from the browser (using javascript).


Year 17 Day 287 12:56
I'm still trying to figure out why you'd rather set up an http proxy instead of setting up a much simpler method by wrapping the API calls on your server side, that way you can do your own caching that can't be overridden by the end user. To each their own, I guess. Either way, I do still strongly suggest you not use the API to get Combine time. There's no real reason to fetch it from the server when it's easily calculated on the client side, and we already provide iframe-based methods of creating a Combine clock (which I'm assuming is what you're attempting to do in that particular case).

I'm rather interested, why exactly don't you want to wrap it on your server side? What's the benefit of calling it directly from the client? Not that that's wrong (I didn't see that "client-side application" document before because it doesn't strike me as particularly useful), but you're putting the control of your dataflow in the hands of the client user, which means they could decide to override whatever Javascript you're using with their own to ping the server over and over again in quick succession, eventually using up all of your allowed requests. As well, what if a user comes to your site and doesn't have Javascript enabled? Are they just SOL because you're forcing Javascript to be the primary way of getting data?

Year 17 Day 287 13:08
Yea, getting the combine time was just an example. I was trying all the calls - planets, classes, news, etc. I'll be primarily wanting to get who the user is via Oauth, and basic information about their skills, maybe their inventory. Probably all read operations as well.

If you're interested in learning about client-side development and it's place/value, I'd suggest googling. You'll surely find better explanations, as I'm no pro. It's just whatever you're comfortable with, I suppose. I'm very comfortable with it and want to do some fun project on my own.

Security-wise there are some baseline precautions you can take - putting everything inside of Immediately-Invoked Function Expressions so that you are only making public the javascript methods that the application needs to share to it's different components. Yet, the user could potentially find those out, yes. You can also uglify and even obfuscate it. And yes, that can be reverse hacked but it would probably take a very LONG time and a lot of dedication. :D Finally, I am able to write specific database rules so that certain are only able to read/write specific collections in firebase (which is noSql) so that even if they did reverse-engineer they can only really damage the data I allow them access to.

Yes, all modern browsers have javascript enabled by default. 90%+ of the internet is javascript enabled things. It will definitely be required for users to have javascript enabled, as it's no longer 1990 :D.

EDIT: This is the second thread where I've seen people discouraging others from using the Combine's API for stuff. I'm sure people spent a lot of time and effort creating that API and it's purpose is to allow people to communicate with the Combine. Is that not it's purpose? I would think reasonable limits to prevent abuse would be implemented on the Combine's side...

Edited By: Tholme So on Year 17 Day 287 13:15

Year 17 Day 287 13:14
I'm a web developer myself and I personally avoid client-driven development purely because I don't see any benefit to it and all documentation I've ever read on it just sells me even less on it. It seems wasteful and it also cuts down your potential clients because you're limiting them to having certain inconsistent functionality in their browser, which isn't always available or isn't always wanted.

As for what you're doing, that definitely sounds like something that should be handled server side to me. You could cache it on the server, thus preventing them from refreshing the cache when they want to refresh it, because that information isn't going to change for long periods of time. Sorry, I just don't get the need of doing this on the client side. ;^ .^

Edit: I'm not trying to discourage you from using the API. I use the API myself. I'm discouraging you from trusting clients to use the API correctly. I'm sorry, it's just bad design to isolate that 10%. The way the web SHOULD work is pages should be populated with static information that gets overwritten if Javascript is available and is able to automatically update the information. There are plenty of users, such as TOR users, who frequently have Javascript disabled because it compromises security.

And there are reasonable limits to prevent abuse on the Combine's side. That's what rate limits are for. It should cut off API access after 150 requests in an hour, which is why caching is suggested.

In the case of Combine's API and the information you're getting back, I honestly can't fathom a single reason you'd want to be able to get data on the fly from the API outside of populating things on the fly (which IMO should be populated once sent to the client to begin with). Information changes so infrequently in Combine that having "real time access" to the API doesn't really matter much.

Also, obfuscation != security. Even suggesting that as a way to prevent people from figuring out what your code is going is silly. It's pretty easy to find where the ajax calls are at in your code and then "deducing" how they're working.

Last time I saw someone using firebase, they ended up having to switch database engines because of optimization problems and all sorts of other fun bugs they ran into >.>

Edit 2: However, this isn't really the place to discuss the usage of the API. We can leave that to the API forums!

Edited By: Ulrike Rayne Schultheiss on Year 17 Day 287 13:29
Year 17 Day 287 13:44
It's not going to update frequently, I've used firebase before and am comfortable with it, and I have no problem excluding users that don't use chrome, firefox, safari, or ie +8. I think we disagree on some things and that's fair.

I'll say 3 big motivating factors for me going this way is I don't have to pay for a server, don't have to setup a server, and don't have to maintain a server. I can instead use that time to drink beer and make another feature! :D

However, I will need a server now since the api endpoints are unprotected. If the combine were super concerned with security then shouldn't those endpoints be all ssl? If they'really not that worried then I guess I don't feel like my stuff has to be ironclad.


Year 17 Day 287 13:51
Ah, so you want to offload what your server should be doing to other people's resources. As for SSL, I'm pretty sure nothing in Combine actually supports SSL. The IRC server doesn't have SSL, Combine itself doesn't have SSL. It's not about security of data. It's about wasting server resources.

Edited By: Ulrike Rayne Schultheiss on Year 17 Day 287 14:11
Year 17 Day 287 13:54
Well if it's about not wasting server resources, I guess a client side app that offloads things from the server should be a great fit. :)

I'm making a website-like interface, not a unity game, lol.


Year 17 Day 287 20:17
This question can be closed. I have a working solution now.