The concept of 'RESTful URIs' is common, but it doesn't appear in the original dissertation, and it doesn't make much sense; because of HATEOAS¹, you shouldn't ever need to know what the URIs are.
> I'm not sure about the hypertext part, because I don't understand what hypertext means here. Is Bitcoinica's interface considered hypertext-driven?
It means that the docs should only have to document a single URI (the entrypoint) and the formats, which should have links to the various parts of the API.
For example, you could have an URI, say 'bitcoinica.com/api'. Then you GET that, and it returns a JSON file with the following key/value:
"ticker": "http://bitcoinica.com/api/ticker"
Now the client knows how to get to the Ticker. Then you GET that, and you receive a new list:
{ "btc-dlr" : "http://.../api/ticker/btc-dlr", "btc-eur": "http://.../apu/ticker/btc-eur", ...
Now the client knows how to request a certain currency pair.
This means the URLs can change without breaking all the existing clients.
In general, I'd say this is "kind-of" RESTful. It doesn't follow HATEOAS and it uses custom formats² (it's inevitable, since there's no standard for this). Having URLs for each concept and reusing HTTP methods and auth is RESTful, though.
¹ Hypermedia as the Engine of Application State
² JSON and XML aren't really formats, they're more like transport mechanisms. Formats are KML, MathML, atom, etc.
The point is that knowing it's XML or JSON tells you nothing, your clients are still completely tied to their API. It's just nice not having to write a parser, but it's not a standard format.