Knowledge-Based Computing and Version 2.0 of the Wolfram|Alpha API
Wolfram|Alpha is making possible a whole new very interesting and very powerful kind of computing. And with the release today of version 2.0 of the Wolfram|Alpha API, it’s going to be considerably easier for a broad range of software developers to take advantage of it.
I’m happy to say that it seems as if Wolfram|Alpha is pretty useful to humans—for example through the wolframalpha.com website. But it also turns out that Wolfram|Alpha is extremely useful to programs. And in fact, even today, the number of requests coming to Wolfram|Alpha each second from programs often exceeds by some margin all the requests coming directly from humans.
The reason for this popularity is really pretty simple: Wolfram|Alpha completely changes the economics of a lot of programming. You see, these days a remarkable number of programs rely on having some kind of knowledge. And traditionally, the only way to get knowledge into a program was for the programmer to painstakingly put it there.
But with Wolfram|Alpha in the picture, it’s a different story. Because built into Wolfram|Alpha is already a huge amount of computable knowledge. And if a program is connected to Wolfram|Alpha, then it can immediately make use of all that knowledge.
Whether one’s building a website or a mobile app or desktop software or an enterprise application, the point is that one can use Wolfram|Alpha as a “knowledge-based computing” platform—so that having all sorts of computable knowledge becomes effectively free from an engineering point of view.
How does a program communicate with Wolfram|Alpha? It uses the Wolfram|Alpha API. (These days, API is pretty much a term on its own, but it comes from “Application Program Interface”.)
Well, if you were a program, all you’d do is instead use a URI of the form http://api.wolframalpha.com/… And what you’d get back is a structure that you could use inside your program.
Like most modern APIs, the Wolfram|Alpha API is a so-called REST-style API, that returns XML output.
That XML output can contain all sorts of different elements. It can have a big HTML structure, suitable for reproducing a whole Wolfram|Alpha output page. Or it can have individual images, or text, that correspond to particular pods or parts of pods in the Wolfram|Alpha output.
It can also have a complete symbolic representation of each piece of the output, given as a Mathematica symbolic expression.
Needless to say, there are all sorts of detailed controls provided. For determining the geolocation to assume. For specifying whether results should come back synchronously all together, or asynchronously in pieces when they are ready. And so on.
There’s also a whole extended language for Wolfram|Alpha queries, that makes it possible to specify for example which particular output pods should be generated, or what assumptions should be made about the types of objects in the input.
All of these capabilities can ultimately be accessed just by sending the appropriate string to the Wolfram|Alpha servers. But as a convenience, there are now libraries for many common languages (.Net, Perl, Python, Ruby, PHP, and Java, not to mention Mathematica) that set up the request string, and then manipulate the resulting structure that comes back. (The Mathematica case is particularly convenient, because it’s a symbolic language, so one can easily deal with arbitrary structures—and it’s interactive, so one can see everything immediately.)
Many of the language libraries for the Wolfram|Alpha API were actually contributed by software developers in the Wolfram|Alpha community (thanks!). There are more to come, as well as SDKs (=“software development kits”) for a variety of environments and platforms.
One way that the Wolfram|Alpha API can be used is for adding Wolfram|Alpha capabilities to websites. But it can be used inside any software system—on a desktop (as with Mathematica), on a server or in the cloud (as with webMathematica), or in any kind of mobile or other device. (And, for example, all Wolfram|Alpha apps, and Wolfram Course Assistant apps, are built using the Wolfram|Alpha API.)
There are a lot of software projects that are already using the Wolfram|Alpha API. One notable example is Bing at Microsoft, where queries are sent from the Bing search engine to the Wolfram|Alpha API. Another example, of a quite different character, is in Touch Press ebooks, where Wolfram|Alpha is used to generate dynamic elements in the books.
What’s happening today with version 2.0 of the Wolfram|Alpha API is that we’re opening up a lot more to software developers. There’s streamlining and extension in the API itself. And we’re simplifying the licensing requirements for the API—notably so that anyone can get started for free using the API.
Creating an API that’s widely used is quite a responsibility. There are server clouds to keep running well. There are compatibilities to maintain. There are users to support.
But we know what we’re getting into. Because we’ve had an API for Mathematica for 21 years—since well before anyone had ever heard of an API. The MathLink API for Mathematica is quite sophisticated. It’s allowed external programs to communicate with Mathematica since 1990. And in fact Mathematica uses it extensively itself, notably in connecting its user interface (“front end”) to its computational kernel, and in setting up distributed computation.
As we build new things with the technology of Wolfram|Alpha—and there are a lot in the pipeline—they are essentially all based on the Wolfram|Alpha API. But what we’re doing internally is soon going to be completely dwarfed by what outside developers are doing with the Wolfram|Alpha API.
I don’t know all the projects that are underway. But of those I know, what’s most remarkable is their diversity. They’re all ultimately using the same Wolfram|Alpha platform. But what they’re doing with it is vastly different.
Beginning to build out the first generation of what’s made possible by the concept of knowledge-based computing that Wolfram|Alpha has introduced…
The v2 API is giving me a 302 and then a 404:
# xxx has my actual API key
$ wget http://api.wolframalpha.com/v2/query?appid=xxx&input=boston&format=image,plaintext
Resolving api.wolframalpha.com… 188.8.131.52, 184.108.40.206, 220.127.116.11, …
Connecting to api.wolframalpha.com|18.104.22.168|:80… connected.
HTTP request sent, awaiting response… 302 Found
Location: http://www.wolframalpha.com/v2/query?appid=xxx [following]
–2011-01-21 09:44:04– http://www.wolframalpha.com/v2/query?appid=xxx
Resolving http://www.wolframalpha.com... 22.214.171.124, 126.96.36.199, 188.8.131.52, …
Connecting to http://www.wolframalpha.com|184.108.40.206|:80… connected.
HTTP request sent, awaiting response… 404 Not Found
I’m guessing the API explorer isn’t working for the same reason.
At least I have no problem using the v1 API 🙂
Hello CldWalker, Thank you for letting us know what you were experiencing. Overnight we discovered a bug that caused the 302 and 404 errors. This bug has been fixed. Please let us know if you continue to experience this. Thank you.
Great move. With API’s all the rage these days and especially REST API’s this is an excellent step forward. Now we can mash up all sorts of great calculations in our apps. Looking forward to lots of great apps coming from this move.
I am getting the same issue as cldwalker. a 403, redirecting to http://www.wolframalpha.com then a 404. I figured maybe it was my implimentation as I fully impliment my own http handler (see below):
my headers are:
GET /v2/query?input=pi&appid=API_KEY HTTP/1.0\n
I figured it out guys, you MUST specify the &format= part…. otherwise it 403s. i use &format=image,plaintext and this works:
Hello Peter C, Thank you for letting us know what you were experiencing. The format parameter is not required in the API request. Overnight we discovered a bug that caused the 302 and 404 errors. This bug has been fixed. Please let us know if you continue to experience this. Thank you.
what are the rate limits?
The simplest requirement is for an API which allowed the user to send the W|A input in a text field and receive the result in a text field of a certain length or a decimal field of a certain length plus a certain number of decimal places.
Something like this
Move ‘2+2’ TOWA 3A
Receive FROMWA 30 (3 Digits and no decimal places)
There might be multiple ‘Receive’ fields to match the expected result.
This would be enough for a large number of users .. What would be the current code needed in API V2.0 ?
Please can Wolfram create a barebones Object Oriented Programming language that includes the functions of this API. Many users will not wish to learn a complex language like Visual Basic when they only need the OOL commands:-
IF THEN ELSE
Perhaps as an expansion of Widgets.
I’d love to see an Actionscript version!
[…] primary goal with the launch of version 2 of the API in January was to open Wolfram|Alpha to all developers and their broad spectrum of clever […]