Javascript JSONP style interface

[Dustin]

Hi Digg API community,

I'm one of the developers for the dojotoolkit's rpc system and I
wanted to add digg in as one of the available endpoints and write a
little blog about how that was done. Dojo's rpc system already
provides access to services based on JsonRPC or JsonpServices with
simple description in the form of json, called SMD. I can and would
like to implement this quickly, but have a question and a feature
request and am wondering what the possibilities of either are :)

1) Can elements that are currently provided as part of the url also be
provided by a querystring parameter? For example, currenly to you
might do /errors/{code}?appkey=foobar.... I'm wondering if this is
also available as some thing like /errors?
code=1001&appkey=foobar.... .

2) In brief testing, the system is millimeters away from working with
the default config, meaning that only a definition (no code) would
even need to be written. The above issue would make that very easy,
but I might be able to work around it if that doesn't work or isn't
going to ever work. The other item however is currently a blocker as
it depends on other parts of the dojo system i'm not wanting to fiddle
with. The issue is simply that the callback function name passed to
the api is not accepted by the digg api and instead returns an
'alert('A Digg API request has an invalid callback argument.');' The
string passed as the callback parameter
'dojo.io.script.jsonp_dojoIoScript1._jsonpCallback'

This function is of course hooked up and managed in the background for
the dojo user so none of the complexity of jsonp style callbacks are
required and also to ensure there is no collision of function names
for callbacks. These functions are isolated to holder in the
providing packages namespace as appropriate, however the digg api
doesn't seem to like the fact that there are periods in the callback
function name, though they are neither inappropriate or invalid. I've
also verified that is not the underscores that it doesn't like. Would
it be possible to relax this restriction on the callback parameter?

Thanks,
Dustin

[ku...@digg.com]

On Nov 1, 9:18 pm, Dustin <dustin.ma...@gmail.com> wrote:
>
> 1) Can elements that are currently provided as part of the url also be
> provided by a querystring parameter? For example, currenly to you
> might do /errors/{code}?appkey=foobar.... I'm wondering if this is
> also available as some thing like /errors?
> code=1001&appkey=foobar.... .
>

No. Currently the API only responds to requests in the fashion that is
documented here: http://apidoc.digg.com/. When attempting to use query
string parameters that aren't supported you should receive an
"Unrecognized argument" error.

> however the digg api
> doesn't seem to like the fact that there are periods in the callback
> function name, though they are neither inappropriate or invalid.

The Javascript response type decodes the JSON response and passes the
data to a Javascript callback function you specify in the callback
argument in the request. I believe the '.' character is not valid in a
Javascript function name, thus the restriction.

[ku...@digg.com]

On Nov 2, 12:13 am, k...@digg.com wrote:
> I believe the '.' character is not valid in a
> Javascript function name, thus the restriction.

This is incorrect, the period certainly is valid. We will take a look
at relaxing the restriction.

-Kurt

[Dustin]

Thanks.

[Steve Williams]

At 08:18 PM 11/1/2007, Dustin wrote:
>... the callback function name ... is not accepted by the digg api
>... 'dojo.io.script.jsonp_dojoIoScript1._jsonpCallback'
>
>... the digg api doesn't seem to like the fact that there are

>periods in the callback function name, though they are neither
>inappropriate or invalid.

True, the dots are not invalid. We restricted the callback arg to
just a simple identifier so that we wouldn't have to do any analysis
to prove there's no vulnerability in allowing operators like
dot. (Micah even suggested we allow square brackets, too, but I got
scared and ran away.)

>Would it be possible to relax this restriction on the callback parameter?

It's possible, but first let me ask you: Would it be onerous to
assign a reference to the function to a variable and then use that
variable as the callback?

The typical pattern for the type=javascript API call is:

<script>
function blee(jsonData) {
...
}
</script>
<script
src="http://services.digg.com/...?type=javascript&callback=blee..."></script>

In your case, you would calculate the function reference in the first
script tag.

<script>
blee = dojo.io.script.jsonp_dojoIoScript1._jsonpCallback;
</script>

I realize that's less elegant, and that may be enough of an argument,
but how much worse would it be? Or does it preclude the use of your
library altogether?

I'm not trying to talk you out of it. I'm sorta trying to talk
myself more completely into the need for dots.

[Pat Diven II]

Steve's right, dots can be referenced, but I'm rallying for url-encoded brackets in the callback.  : )

My problem is that I'm making a variable number of requests to the Digg API on a page, and it's crucial that the responses be handled in a certain order by unique functions.

My solution, which I've utilized with the Yahoo API, is to use a JavaScript array (dynamically generated) as a sort of 'variable' variable to reference functions.  This allows me to sort of 'tag' responses.  Example:

unique_functions[0] = function (r) { }
unique_functions[1] = function (r) { }
...

So I'm looking to call the Digg API as such:
http://services.digg.com/topics?appkey=http%3A%2F%2Fexample.com&type=javascript&callback=unique_functions%5B4%5D

( 'unique_functions%5B4%5D' is the url-encoded 'unique_functions[4]' )

Unfortunately, that's not possible yet.

I know that allowing url-encoded brackets will require some vulnerability checking, but if it's any comfort, Yahoo's API specifically allows url-encoded brackets in the callback:

http://developer.yahoo.com/common/json.html
"Important: brackets requested in callbacks must be URL encoded"

Thanks!

[Steve Williams]

Thanks for the additional data point. I'll discuss it with our
Javascript guru again, but I can't promise we'll support callbacks
other than simple identifier names.

At 01:53 PM 6/24/2008, Pat Diven II wrote:
>... it's crucial that the responses be handled in a certain order by
>unique functions.
>
>My solution ... a JavaScript array ...

I'm curious. How does the array ensure that the responses are
handled in a certain order? (Be gentle with me. I'm no Javascript expert.)

[PC]

Thanks, Steve!

> ... but I can't promise we'll support callbacks

> other than simple identifier names.

It's the only way we'll be able to know which response is which among
multiple responses, since our identifier names are dynamic. If you're
wondering about the application, it's an embeddable bit that others
may initiate more than once on a page, which is why we're using
dynamic identifier names. We need that callback. ; )

> How does the array ensure that the responses are
> handled in a certain order?

I used the wrong word. Order doesn't matter; pairing does. What's
imperative is that we make sure we pair responses with the correct
functions.

[Steve Williams]

At 07:57 PM 6/24/2008, PC wrote:
>What's imperative is that we make sure we pair responses with the
>correct functions.

This sounds really interesting. Can you give a bit more complete
example? I'd like to see the Javascript code that sets up the array
in context with the API requests. Maybe you can point to an example
page that doesn't work because of the constraints on the callback value?

[mi...@digg.com]

On Jun 24, 6:54 pm, Steve Williams <s...@digg.com> wrote:

> Thanks for the additional data point.  I'll discuss it with our
> Javascript guru again, but I can't promise we'll support callbacks
> other than simple identifier names.

That discussion happened, and we've decided to allow member operators
as well as regular identifiers. Good news for everyone, right?

For reference (and this isn't official until you see it in the API
docs, and of course it's still subject to tweaks) we plan to expand
our check to include:

Almost any legal identifier* -
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Variables#Variables
Bracket and dot member operators -
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Operators:Member_Operators

*Note: There should eventually be full Unicode support for
identifiers, but I'm not the guy who owns that code so I'll avoid
making promises on the API team's behalf. For now, stick to _$a-Z.

Cheers,
- Micah

[PC]

Steve, Micah: you both rock! Thank you.

Steve, I'll see about posting a testcase here sometime after lunch.

On Jun 25, 12:30 pm, mi...@digg.com wrote:
> On Jun 24, 6:54 pm, Steve Williams <s...@digg.com> wrote:
>
> > Thanks for the additional data point.  I'll discuss it with our
> > Javascript guru again, but I can't promise we'll support callbacks
> > other than simple identifier names.
>
> That discussion happened, and we've decided to allow member operators
> as well as regular identifiers. Good news for everyone, right?
>
> For reference (and this isn't official until you see it in the API
> docs, and of course it's still subject to tweaks) we plan to expand
> our check to include:
>

> Almost any legal identifier* -http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Variab...
> Bracket and dot member operators -http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Op...

[Pat Diven II]

That discussion happened, and we've decided to allow member operators as well as regular identifiers.

Any idea when this will happen?  Thanks.

[Steve Williams]

Sorry this has taken so long. We've been busy with some bigger API
tasks, but I'll try to get this back on the front burner.

How are you planning to use it?

[Pat]

> We've been busy with some bigger API
> tasks, but I'll try to get this back on the front burner.

Certainly appreciated!

> How are you planning to use it?

In a widely used widget to show the digg count of a story.