Folding Forum

I seem to be getting errors (HTTP500s) on specific APIs:
http://folding.stanford.edu/stats/api/d ... rtdos_solo
stanfordmodern.js:27 Uncaught TypeError: $(...).ceebox is not a function
at HTMLDocument.<anonymous> (stanfordmodern.js:27)
at l (jquery-1.8.3.min.js:2)
at Object.fireWith [as resolveWith] (jquery-1.8.3.min.js:2)
at Function.ready (jquery-1.8.3.min.js:2)
at HTMLDocument.A (jquery-1.8.3.min.js:2)
(anonymous) @ stanfordmodern.js:27
l @ jquery-1.8.3.min.js:2
fireWith @ jquery-1.8.3.min.js:2
ready @ jquery-1.8.3.min.js:2
A @ jquery-1.8.3.min.js:2

What are you tring to do? Are you trying to hack FAHClient's API or use it as a web browser? That's not what it's designed to do.
Which FAH server are you trying to open?

FAHClient is a closed source process that acts much like a browser and it's sole purposed is to download proprietary data, have it processed, and return it to the assigning FAH server. The EULA specificially prohibits downloading /processing /uploading FAH's data by any other means. THis is NOT where you get stats data, which is the subject of this topic.

I don't see why you're trying to use it instead of using a standard browser.

The server status page at http://fah-web.stanford.edu/pybeta/serverstat.html lists many of sthe errvers used by FAH. At any one time, many servers are operational, but some are not. Right now, the second on on the list is operational and the server status page http://128.252.203.2/ shows a banner page indicating that Work Server Version 9.0.8 is running on that server. The first sever on the list is currently down and if I open http://171.65.103.160/ I will receive a HTML500 timeout message.

You don't need to use FAHClient to do that for you ... use a standard browser.

Well, I have a Powershell script that calls the APIs by URI and uses the JSON responses to parse through my stats data and save it off. If I need to add logic to systematically try other servers, I can. I would just expect that calling by URI would resolve to a working server.

Which URI are you trying to use?
... and why?

http://folding.stanford.edu/stats/api/donor/bobertdos_solo
These APIs are publicly documented on the stats page for exactly this type of use. Most are working. It seems to be the donor ones that are not.

OK.

I don't use the APIs so I can't answer specific questions about them but I can forward this request to someone who can. Presumably you're reporting a broken or missing API.

First of all, I must say that direct acess to the stats has been limited due to the performance impact it has on providing stats to everyone, whether it's through the API or through soe other type of scripted query process and you may be banned for overused of that tupe of access. THe alternative is a series of flat-files containing the same information which are provided for those sites which wish to reprocess them as a 3rd party. (I suspect you're trying to gather enough information to publish your own stats pages.)

Please do not use scripts to access our main pages (i.e. anything with a cgi-bin in the url). We reserve the right to ban any IP that violates this rule, as it slows down the stats for everyone else.

Please use:
http://fah-web.stanford.edu/daily_user_summary.txt.bz2
http://fah-web.stanford.edu/daily_team_summary.txt.bz2
(or the same files without the .bz2 suffix)

They should be updated on a regular basis.

Dues that allow you to do what you're trying to do?

They would, with some modifications. I don't mean to negatively impact performance or cause problems. I've only been creating a record of my own stats, no one else's. I just figured that's why the APIs were available, otherwise, why have them be public?

This is the answer provided by FAH's development team.

You're using our API incorrectly. To access the donor's data, you first need the donor's ID. You can search for ids like this:
http://folding.stanford.edu/stats/api/d ... rtdos_solo

Then look up one of the returned ids like this:
http://folding.stanford.edu/stats/api/donor/1780372

The Stanford proxy returns 500 and hides the error message returned by our stats server This is unfortunate but not a big deal.

Ohh, that makes sense! It conforms better to how the rest of the stats pages work too. I'm surprised the server let me get away with using it the other way for such a long time. I thank you for understanding though and passing my question along, Bruce. Working with REST APIs is not exactly a typical day to day activity and I totally get that. I just happen to be one of the weirdos who likes that stuff.