Exclusive details on the DDI API (not a repeat...)

Stop getting caught up in legalese. Seriously.

As long as you're not doing it for profit, you won't get sued. I promise. Worst case scenario, they'll send you a C&D.

... snip ...

It is absolutely clear that this is what Wizards of the Coast wants people to do.

IMO, this is bad advice. Working for a very major corporation, and having mandatory yearly education on this sort of stuff, generally, when in doubt, the first step is to stop and consult the legal team.

In this case, I don't think Mr. Rouse's posting is sufficient to present the WotC policy. I would be careful until the online agreement and until the posted policy on the website are updated. Mr. Rouse's posting is a positive sign, but until there is an update that is clearly from the WotC legal team, some care should be used. (I'm actually surprised at the posting the Mr Rouse has made: That could put WotC in some danger, and is the sort of statement that usually has to be put through legal clearances. I can't tell if that has been done. If it has, my apologies. In this case, absent a very clear statement that the policy has legal approval, I can't accept it as a definitive statement. Also, this is an area where you really don't want multiple streams of statements. That muddies the water where you want very clear policies.)

Basically, I'm looking for an official statement that appears on the WotC website that can be provided through a link.

[PostScript: Under the DMCA, a Cease and Desist is not nearly the worst case scenario.]

Thx!

TomB
 
Last edited:

log in or register to remove this ad

Yeah, I guess you are right. That is what has been done thus far is to send C&Ds. But I figured they'd go to account banning before that if you were automating the extraction of data and they didn't like it. The only reason I had not taken an interest thus far was to avoid getting my account removed for automating access to it - something I'd not like to happen if I'd paid for an extended amount of access to DDI.

Thanks for bringing up the topic. Hopefully, this is a good step and as I said, I look forward to the upcoming article about it.

It's worth noting that I don't actually get access to any data behind the paywall... All I'm getting is the search results anyone can find, and the links anyone can find.

I can send you to the page, but you still need to log yourself in.

Now, theoretically it would be possible to log in and scrape the database (and, indeed, I've been in contact with people who have claimed to have done just that in months prior), but that doesn't require the API at all.
 

It's worth noting that I don't actually get access to any data behind the paywall... All I'm getting is the search results anyone can find, and the links anyone can find.

I can send you to the page, but you still need to log yourself in.

Now, theoretically it would be possible to log in and scrape the database (and, indeed, I've been in contact with people who have claimed to have done just that in months prior), but that doesn't require the API at all.

Right. I understand that this is totally different from screen scraping and it is clear that they are documenting the API. I took a look at the Compendium Search service and noticed that everything accessible through its operations is data that is accessible to the public without having to log in. If there is no access to data that requires a login then I suspect the legal questions still stand about automated access to it (and I suspect that operations like that are against the TOS). I hoped that the next article might provide access (with authentication) to the data through the API.

Here's to hoping.
 

Some usage that seems problematic ...

Thinking more about the access, there are a couple of access types that seem to be problematic:

1) Anything that does queries and caches the results;
2) (1), where the cache is made available to other people.
3) Providing a forwarding service, where a third part contacts you through an API of your design, which prompts your API to log into the for-pay DDI using your login information to complete the request.

In a group environment, I can see (3) being very useful, where the DM and players each has network access, and where the DM has a portal to the DDI, and where the players access the DDI through the DM's portal. That seems useful enough, and simple enough to implement, that folks are very probably already thinking about doing it. That also seems to be exactly what WotC would not approve of.

Note that a web-site may have a policy that prohibits access to secondary pages without your having visited initial pages, and this is (?) actionable (?) enforceable, and has been tested through case law.
 
Last edited:

It's worth noting that I don't actually get access to any data behind the paywall... All I'm getting is the search results anyone can find, and the links anyone can find.

I can send you to the page, but you still need to log yourself in.

Now, theoretically it would be possible to log in and scrape the database (and, indeed, I've been in contact with people who have claimed to have done just that in months prior), but that doesn't require the API at all.

Yeah, I could code up an automator script to get safari to pull everything down, but that would still be my web browser getting the info.

On a related note, have you figured out what the code is to log in. obviously you'd want to post email and password but I still haven't figured out where that goes.
 
Last edited:

Yeah, I could code up an automator script to get safari to pull everything down, but that would still be my web browser getting the info.

On a related note, have you figured out what the code is to log in. obviously you'd want to post email and password but I still haven't figured out where that goes.

Looks to be login.aspx

<form name="form1" method="post" action="login.aspx?page=monster&id=2351" id="form1">

Here're the relevant bits:

<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWBAK5u9HLAQKyzcaDDQLyveCRDwK4+vrXBTI0l5j0hL3ej514UF0fpXH07GN4" />
<input name="email" type="text" id="email" />
<input name="password" type="password" id="password" />
 



The second part of the info on the API went up D&D Insider: Compendium API - Part 2 yesterday.

One thing to note is that in my testing, null is needed instead of NULL in the filters. I saw the KeywordSearchWithFilters method the other day, but now that the filter strings have been disclosed, it makes it really useful.

Apparently they will be disclosing how to get to the data in a third article which addresses "security issues and concerns". This does indeed look promising and it is clearly meant for automation, but I still think that their TOS conflicts with the use of this. Perhaps it will get a refresh.
 

Apparently they will be disclosing how to get to the data in a third article which addresses "security issues and concerns". This does indeed look promising and it is clearly meant for automation, but I still think that their TOS conflicts with the use of this. Perhaps it will get a refresh.

There's a fanpage policy in the works... Should have been out a while ago, frankly, though given the timeline of the vastly-more-important GSL I'm not all that surprised by the delay. My guess is that it's "in legal," since that seems to be the usual refrain.
 

Remove ads

Top