We definitely have a Fantasy Sports specific OAuth scope, so that'll certainly be your problem if you weren't able to register for it. Looking over the [url="https://developer.apps.yahoo.com/dashboard/createKey.html"]New API Key[/url] flow, we should be showing up with either a Read or Read/Write scope if you select the "This app requires access to private user data." option -- as you've noticed, though, we don't actually seem to be there. :oYou should still be able to use the YQL tables to explore the schema for a bit in the meantime. Sorry for the delay!

[quote name='Sean Montgomery' date='Jun 2 2010, 08:19 PM' post='15837']
You should still be able to use the YQL tables to explore the schema for a bit in the meantime. Sorry for the delay!
[/quote]

Thanks! That's reassuring, that it's not me. :)Sujal

I opened the YQL console and copy/pasted the first REST query in my browser's address bar
http://query.yahooapis.com/v1/yql?q=select%20*%20from%20fantasysports.games%20where%20game_key%3D%22238%22&diagnostics=true
this returns a xml error: Please provide valid credentials

is this expected ? or is this linked to the problem above ?
will we need credentials to run this simple query ? if so, which one ? an API key ?

The actual API implementation should match what we have in the documentation, but the YQL bindings currently only cover a subset. You can only get the basic metadata for each of the primary resources, plus a couple of other useful subresources like scoreboards, standings, or draft results. We'll most likely be trying to augment our YQL data tables in future, but we wanted to get the old-school URL-based webservices out the door first.

So don't try to hard to figure out anything hidden with the YQL tables -- it's mostly "what you see is what you get", aside from the players table which has some extra filters in place (position, status, and a variety of sorts).

[quote name='Sean Montgomery' date='Jun 2 2010, 08:36 PM' post='15840']
The actual API implementation should match what we have in the documentation, but the YQL bindings currently only cover a subset. You can only get the basic metadata for each of the primary resources, plus a couple of other useful subresources like scoreboards, standings, or draft results. We'll most likely be trying to augment our YQL data tables in future, but we wanted to get the old-school URL-based webservices out the door first.

So don't try to hard to figure out anything hidden with the YQL tables -- it's mostly "what you see is what you get", aside from the players table which has some extra filters in place (position, status, and a variety of sorts).
[/quote]

Sean, thanks for the quick responses. Itching to try this to see if it will help me build some tools for my commish. Hopefully you'll get that oauth switch flipped soon and I can start playing around.

Thanks,

Sujal

@Pickemfirst Dev:
From the YQL docs -- http://developer.yahoo.com/yql/guide/yql_url.html -- it looks like the /yql YQL query actually still requires you to use OAuth (even for public information).

"The next URL requires authorization by OAuth and allows access to both public and private data:

http://query.yahooapis.com/v1/yql?[query_params] "

So you won't easily be able to pull out XML from YQL without at least setting up some sort of OAuth key with us. Like I mentioned, you should be able to get a general access Project by going through the "New API Key" flow. You'll just need to wait until we can get the Fantasy Sports OAuth scope gets turned on before you can query our fantasy servers directly.

Thanks Sean for the clarification.

one more question:
How will I attach the OAuth key to my query in my web application ?
or is it automatically done based on the requester's address ?

@Pickemfirst Dev:
[quote name='Pickemfirst Dev' date='Jun 2 2010, 08:51 PM' post='15845']
one more question:
How will I attach the OAuth key to my query in my web application ?
or is it automatically done based on the requester's address ?
[/quote]

Ha, I was just playing around with that when we were testing out the services.

If you want to construct the OAuth parameters manually, you can go through our OAuth documentation -- http://developer.yahoo.com/oauth/ -- which provides a really solid coverage of how all of this OAuth stuff works. The good stuff starts here:

http://developer.yahoo.com/oauth/guide/oauth-auth-flow.html

However, it's definitely a bit of a hassle to construct the parameters (which, BTW, can be passed either as URL params or as part of the HTTP header) and the signature generation can get very tricky. I'd recommend using one of the standard libraries out there for OAuth. You can find most of them linked to from here: http://oauth.net/code/ . The PHP library, for instance, just boils down to hardcoding your consumer key/secret, making a couple of one-line token requests (storing some state as you go along), and then fetching your data. We'll hopefully get some sample applications thrown together over the next couple weeks.

Thanks!

I guess I'll learn how to use a Java OAuth library while waiting for the Fantasy Sports OAuth scope

Looks like we should have the scopes available by early next week, tentatively planned for Monday morning. Coordinating schedules is hard. :PIn the meantime, you should be able to play around with the YQL console and read over documentation. Sorry for the delay!

Tada! My thanks to our OAuth guys for getting this taken care of.

:D

I'm having issues with this, I get the access token using the standard ruby oauth library, but it keeps returning this:

{"error"=>{"lang"=>"en-US", "description"=>"Authentication Error. The table fantasysports.games requires a higher security level than is provided, you provided ANY but at least USER is expected"}}

q = 'select * from fantasysports.games where game_key="nfl"' # this works fine in the YQL console.

This is the code to call it: @access_token.get("http://query.yahooapis.com/v1/public/yql?format=json&q=#{CGI::escape(q)}"

Has anyone had success using the ruby oauth library?

If I'm not mistaken, we don't have any support for non-3-legged OAuth through the YQL interface. ie, you'll always need to be in a user context. Does that help clarify the problem? If you are already going through 3-legged OAuth with the Ruby library you're playing with, you might consider going for the private YQL URL instead:

http://query.yahooapis.com/v1/yql?[query_params]