6 ms·

Introducing Bitcoinica API (The first RESTful Bitcoin Trading API)

49 points by zhoutong 15y ago

masklinn 15y ago
> Quotes API Returns latest quote(s) for a given currency pair. > Ticker: > URI: GET https://www.bitcoinica.com/api/quotes/[currency_pair].json https://www.bitcoinica.com/api/quotes/[currency_pair].json That's RPC over HTTP, not a RESTful API. edit: well, apparently HN sides with meaningless keyword-babble, great.
- zhoutong 15y ago
  The request is not transmitted in JSON. So it's not JSON-RPC at least. http://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_services http://en.wikipedia.org/wiki/Representational_state_transfer... - The URI is RESTful. (Explicit collection and member actions, with common namespace.) - Supports both JSON and XML. (Internet media types) - Bitcoinica API utilizes three of the four RESTful Web Services methods - GET, POST and DELETE. (HTTP methods) But I'm not sure about the hypertext part, because I don't understand what hypertext means here. Is Bitcoinica's interface considered hypertext-driven?
  - icebraining 15y ago
    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.
    - DougWebb 15y ago
      I understand the appeal of using json, but it doesn't support hyperlinks. There really ought to be a hyperlink datatype as part of the json standard, with the same attributes that html supports: a label, href, rel, maybe more. The label is human-readable, and rel is machine-readable; both provide the semantic information that identifies what the link is for. The url is given by href, of course. Not having this datatype is a big drawback of json for RESTful responses. That's why I typically design APIs to use xhtml responses instead. They're just as parsable (just a big bit slower) but they're richer and they allow the API to be tested with a browser that has no knowledge of the semantics of the API. I consider the ability to use the API using a generic client to be a good test of properly implementing HATEOAS.
      - swah 15y ago
        Why would an URL type be useful? If JSON responses are {key:value,...}, in both ends 'key' has a meaning, and when you receive {'link':'http://... http://...}, you deal with 'link'... I'm confused.
        DougWebb 15y ago
        It would be useful because it would provide a standard way of expressing a hyperlink. URLs are a standard way of expressing the location of a resource, HTTP is a standard mechanism for interacting with resources, but there are no widely-used standards for expressing "here's a URL". XLink and RDF tried to become standards for that, but they haven't caught on. The text/html content type (and its close relatives) are widely understood and include a couple of syntaxes for different types of links, and that's why I like xhtml as my API content type. If JSON had a standard widely understood syntax for links I'd happily switch over since JSON is certainly more popular as a RESTful API content type. Imagine where we would be if every website expressed links using a different syntax, and browsers had to be explicitly programmed to understand a given website's syntax in order to use its links. The web couldn't exist that way.
        icebraining 15y ago
  - masklinn 15y ago
    > The request is not transmitted in JSON. So it's not JSON-RPC at least. I don't count that as a positive, since it would at least prevent them from calling it restful. > The URI is RESTful. (Explicit collection and member actions, with common namespace.) URIs can not be RESTful, this does not even make sense. > Supports both JSON and XML. (Internet media types) Supporting "JSON" and "XML" is completely useless: they're meta-format, in and of itself outputting "JSON" is completely meaningless as it does not tell the client anything. Defining the exact media types returned (which this API description barely does) is the vast majority of a RESTful application's documentation. In fact, it should be all of the documentation save for a single URL, which is the API's root entry point. > Bitcoinica API utilizes three of the four RESTful Web Services methods - GET, POST and DELETE. (HTTP methods) Better, but still not sufficient to make an API restful. Plus orders are created via a POST, that's not correct, the semantics of POST are updating (creation is PUT) > But I'm not sure about the hypertext part, because I don't understand what hypertext means here. And you don't think that might be an issue in your judgment? > Is Bitcoinica's interface considered hypertext-driven? No, and being hypertext-driven is the most important criteria of a RESTful application.
    - mckoss 15y ago
      POST semantics can be used to CREATE as well. And PUT can also be used to UPDATE. PUT semantics are more like "update_or_create". POST is like "create_child". http://stackoverflow.com/questions/630453/put-vs-post-in-rest http://stackoverflow.com/questions/630453/put-vs-post-in-res...
    - deleted 15y ago
      [deleted]
- strmpnk 15y ago
  (I'd upvote you more but we're in the minority.) I wish people would read about REST [0] before they use the term. Proper use of HTTP is only one prerequisite of an REST over HTTP implementation. [0]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... is a common point missed by most folks.
marcf 15y ago
REST trading APIs? Not exactly HFT. :-)
- pgroves 15y ago
  Maybe that's a feature not a bug.
rb2k_ 15y ago
Great work! I think I will have a lot of fun hacking away on this (yay, weekend project). The only downside is that while I have no idea how I would be able to get a small amount of money (?25 Euros?) to the site. Bank transfers don't run on the weekends and while there is a bunch of ways to get money to mtgox, I don't know if any of them can be fueled by paypal/google checkout/amazon payments/... which operate on the weekends
- zhoutong 15y ago
  That's the common downside of all Bitcoin Trading Platforms. Currently it's virtually impossible to have all three criteria of a good online payment system other than Bitcoin: - Instantly available - Reliable (maybe law-regulated, bank-operated or systematically-controlled) - Non-reversible
JoachimSchipper 15y ago
Note: there was a lot of discussion about security etc last time Bitcoinica came up (http://news.ycombinator.com/item?id=2973301 http://news.ycombinator.com/item?id=2973301). patio11: "My semi-amateurish opinion is that as a non-registered securities dealer with all accounts having margin capabilities the (near 100%) likelihood of your Rails app exploitably broken is not the key source of risk to your business." (http://news.ycombinator.com/item?id=2974695 http://news.ycombinator.com/item?id=2974695) See also e.g. http://news.ycombinator.com/item?id=2974032 http://news.ycombinator.com/item?id=2974032 and http://news.ycombinator.com/item?id=2973429 http://news.ycombinator.com/item?id=2973429 plus tptacek's reply to http://news.ycombinator.com/item?id=2973732 http://news.ycombinator.com/item?id=2973732. On the other hand, Bitcoinica may not be less secure than Mt. Gox...
- zhoutong 15y ago
  I'm actually quite serious about security. But I still feel that the security-related discussions are too overwhelming. Of course I know that nothing is 100% secure, but I can make my bottom-line high. This is not my first project. I have been coding in Rails for almost 3 years, with some failed projects. I also know some security basics because I have hacked websites before (non-destructive). There is always relative security. Ruby on Rails itself is a relatively secure framework. Rails sites have been much less frequently hacked than PHP sites. (Because everything is well wrapped.) I'm also very conservative about using Rails (rarely override methods myself, not even toughing find_by_sql even when it's the easy way). Passwords are stored hashed and salted using BCrypt. Although no explicit security auditing has been done, all the Rails app logs (including requests and IP addresses) are extracted and backed up nightly. Soft-deleting is enabled for all operations, etc. I'm not distracting myself from the real problem, but I have to say that I'm not that kind of random kids who write crappy apps for fun. My use of Heroku is also partly because of security. I use Mac and know a bit of Linux, but I know I can't really set up a Linux box and be sure about the security. Instead I have chosen Heroku's integrated, read-only and cloud-based platform. Sorry for not replying most of the security-related comments. Not because I can't face opposing arguments, but instead, I think they are valuable. However, I hope everyone can be a little bit more reasonable and realistic. Since nothing is secure, security is everyone's problem. Although I don't have anything to prove my security experience, at least this is not the first time I deal with money. I once developed a mini payment gateway (PayPal and credit card) for my friend who used it to process transactions totaling more than $50,000. There're a lot of fraudulent orders, which means that people have an incentive to steal, but the payment system itself has been safe. I can understand that people are skeptical considering my age (or even my Chinese name). But will the Bitcoin community be better off if I shut down the project now? I have chosen Bitcoin because its low barrier to entry and open community, not because I have no bottom-line or security concerns. What I really want to disagree is the view that I must end this project now. There are basically too many people emailing me just to thank me for delivering the features that the big guys (Mt. Gox and TradeHill) can't finish in months. I have taken the extreme minimalistic approach in development of Bitcoinica - no Bitcoin wallets and no unusable features. I make it a pure trading platform - you can't even do money laundering on Bitcoinica. System wise, I don't have to SSH the server to configure anything, and I don't have to even see the database credentials myself. Anyway, I completely accept all the negative viewpoints about Bitcoinica, but I just want to explain clearly that I may not be the person everyone's thinking about.
LeafStorm 15y ago
My problem with Bitcoin is that it is skewed to favor early adopters, but every two weeks or so one hears about a huge Bitcoin site being cracked, a State Department investigation, or a possible vulnerability, or something like that. So, while the concept sounds interesting, it's very likely that if I get in early I will lose all of my Bitcoins to some exploit, and that if I get in late I will not be able to rack up enough Bitcoins to buy anything.
- feydr 15y ago
  there is definitely a very high risk but there is definitely a very high reward -- the keyword here is 'speculation' -- nothing wrong with it as long as you know that that is what it really is

49 points by zhoutong 15y ago

> Quotes API Returns latest quote(s) for a given currency pair. > Ticker: > URI: GET https://www.bitcoinica.com/api/quotes/[currency_pair].json https://www.bitcoinica.com/api/quotes/[currency_pair].json That's RPC over HTTP, not a RESTful API. edit: well, apparently HN sides with meaningless keyword-babble, great.

zhoutong 15y ago
The request is not transmitted in JSON. So it's not JSON-RPC at least. http://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_services http://en.wikipedia.org/wiki/Representational_state_transfer... - The URI is RESTful. (Explicit collection and member actions, with common namespace.) - Supports both JSON and XML. (Internet media types) - Bitcoinica API utilizes three of the four RESTful Web Services methods - GET, POST and DELETE. (HTTP methods) But I'm not sure about the hypertext part, because I don't understand what hypertext means here. Is Bitcoinica's interface considered hypertext-driven?
- icebraining 15y ago
  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.
  - DougWebb 15y ago
    I understand the appeal of using json, but it doesn't support hyperlinks. There really ought to be a hyperlink datatype as part of the json standard, with the same attributes that html supports: a label, href, rel, maybe more. The label is human-readable, and rel is machine-readable; both provide the semantic information that identifies what the link is for. The url is given by href, of course. Not having this datatype is a big drawback of json for RESTful responses. That's why I typically design APIs to use xhtml responses instead. They're just as parsable (just a big bit slower) but they're richer and they allow the API to be tested with a browser that has no knowledge of the semantics of the API. I consider the ability to use the API using a generic client to be a good test of properly implementing HATEOAS.
    - swah 15y ago
      Why would an URL type be useful? If JSON responses are {key:value,...}, in both ends 'key' has a meaning, and when you receive {'link':'http://... http://...}, you deal with 'link'... I'm confused.
      - DougWebb 15y ago
        It would be useful because it would provide a standard way of expressing a hyperlink. URLs are a standard way of expressing the location of a resource, HTTP is a standard mechanism for interacting with resources, but there are no widely-used standards for expressing "here's a URL". XLink and RDF tried to become standards for that, but they haven't caught on. The text/html content type (and its close relatives) are widely understood and include a couple of syntaxes for different types of links, and that's why I like xhtml as my API content type. If JSON had a standard widely understood syntax for links I'd happily switch over since JSON is certainly more popular as a RESTful API content type. Imagine where we would be if every website expressed links using a different syntax, and browsers had to be explicitly programmed to understand a given website's syntax in order to use its links. The web couldn't exist that way.
        icebraining 15y ago
- masklinn 15y ago
  > The request is not transmitted in JSON. So it's not JSON-RPC at least. I don't count that as a positive, since it would at least prevent them from calling it restful. > The URI is RESTful. (Explicit collection and member actions, with common namespace.) URIs can not be RESTful, this does not even make sense. > Supports both JSON and XML. (Internet media types) Supporting "JSON" and "XML" is completely useless: they're meta-format, in and of itself outputting "JSON" is completely meaningless as it does not tell the client anything. Defining the exact media types returned (which this API description barely does) is the vast majority of a RESTful application's documentation. In fact, it should be all of the documentation save for a single URL, which is the API's root entry point. > Bitcoinica API utilizes three of the four RESTful Web Services methods - GET, POST and DELETE. (HTTP methods) Better, but still not sufficient to make an API restful. Plus orders are created via a POST, that's not correct, the semantics of POST are updating (creation is PUT) > But I'm not sure about the hypertext part, because I don't understand what hypertext means here. And you don't think that might be an issue in your judgment? > Is Bitcoinica's interface considered hypertext-driven? No, and being hypertext-driven is the most important criteria of a RESTful application.
  - mckoss 15y ago
    POST semantics can be used to CREATE as well. And PUT can also be used to UPDATE. PUT semantics are more like "update_or_create". POST is like "create_child". http://stackoverflow.com/questions/630453/put-vs-post-in-rest http://stackoverflow.com/questions/630453/put-vs-post-in-res...
  - deleted 15y ago
    [deleted]
strmpnk 15y ago
(I'd upvote you more but we're in the minority.) I wish people would read about REST [0] before they use the term. Proper use of HTTP is only one prerequisite of an REST over HTTP implementation. [0]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... is a common point missed by most folks.

marcf 15y ago

REST trading APIs? Not exactly HFT. :-)

pgroves 15y ago
Maybe that's a feature not a bug.

rb2k_ 15y ago

Great work! I think I will have a lot of fun hacking away on this (yay, weekend project). The only downside is that while I have no idea how I would be able to get a small amount of money (?25 Euros?) to the site. Bank transfers don't run on the weekends and while there is a bunch of ways to get money to mtgox, I don't know if any of them can be fueled by paypal/google checkout/amazon payments/... which operate on the weekends

zhoutong 15y ago
That's the common downside of all Bitcoin Trading Platforms. Currently it's virtually impossible to have all three criteria of a good online payment system other than Bitcoin: - Instantly available - Reliable (maybe law-regulated, bank-operated or systematically-controlled) - Non-reversible

JoachimSchipper 15y ago

Note: there was a lot of discussion about security etc last time Bitcoinica came up (http://news.ycombinator.com/item?id=2973301 http://news.ycombinator.com/item?id=2973301). patio11: "My semi-amateurish opinion is that as a non-registered securities dealer with all accounts having margin capabilities the (near 100%) likelihood of your Rails app exploitably broken is not the key source of risk to your business." (http://news.ycombinator.com/item?id=2974695 http://news.ycombinator.com/item?id=2974695) See also e.g. http://news.ycombinator.com/item?id=2974032 http://news.ycombinator.com/item?id=2974032 and http://news.ycombinator.com/item?id=2973429 http://news.ycombinator.com/item?id=2973429 plus tptacek's reply to http://news.ycombinator.com/item?id=2973732 http://news.ycombinator.com/item?id=2973732. On the other hand, Bitcoinica may not be less secure than Mt. Gox...

zhoutong 15y ago
I'm actually quite serious about security. But I still feel that the security-related discussions are too overwhelming. Of course I know that nothing is 100% secure, but I can make my bottom-line high. This is not my first project. I have been coding in Rails for almost 3 years, with some failed projects. I also know some security basics because I have hacked websites before (non-destructive). There is always relative security. Ruby on Rails itself is a relatively secure framework. Rails sites have been much less frequently hacked than PHP sites. (Because everything is well wrapped.) I'm also very conservative about using Rails (rarely override methods myself, not even toughing find_by_sql even when it's the easy way). Passwords are stored hashed and salted using BCrypt. Although no explicit security auditing has been done, all the Rails app logs (including requests and IP addresses) are extracted and backed up nightly. Soft-deleting is enabled for all operations, etc. I'm not distracting myself from the real problem, but I have to say that I'm not that kind of random kids who write crappy apps for fun. My use of Heroku is also partly because of security. I use Mac and know a bit of Linux, but I know I can't really set up a Linux box and be sure about the security. Instead I have chosen Heroku's integrated, read-only and cloud-based platform. Sorry for not replying most of the security-related comments. Not because I can't face opposing arguments, but instead, I think they are valuable. However, I hope everyone can be a little bit more reasonable and realistic. Since nothing is secure, security is everyone's problem. Although I don't have anything to prove my security experience, at least this is not the first time I deal with money. I once developed a mini payment gateway (PayPal and credit card) for my friend who used it to process transactions totaling more than $50,000. There're a lot of fraudulent orders, which means that people have an incentive to steal, but the payment system itself has been safe. I can understand that people are skeptical considering my age (or even my Chinese name). But will the Bitcoin community be better off if I shut down the project now? I have chosen Bitcoin because its low barrier to entry and open community, not because I have no bottom-line or security concerns. What I really want to disagree is the view that I must end this project now. There are basically too many people emailing me just to thank me for delivering the features that the big guys (Mt. Gox and TradeHill) can't finish in months. I have taken the extreme minimalistic approach in development of Bitcoinica - no Bitcoin wallets and no unusable features. I make it a pure trading platform - you can't even do money laundering on Bitcoinica. System wise, I don't have to SSH the server to configure anything, and I don't have to even see the database credentials myself. Anyway, I completely accept all the negative viewpoints about Bitcoinica, but I just want to explain clearly that I may not be the person everyone's thinking about.

LeafStorm 15y ago

My problem with Bitcoin is that it is skewed to favor early adopters, but every two weeks or so one hears about a huge Bitcoin site being cracked, a State Department investigation, or a possible vulnerability, or something like that. So, while the concept sounds interesting, it's very likely that if I get in early I will lose all of my Bitcoins to some exploit, and that if I get in late I will not be able to rack up enough Bitcoins to buy anything.

feydr 15y ago
there is definitely a very high risk but there is definitely a very high reward -- the keyword here is 'speculation' -- nothing wrong with it as long as you know that that is what it really is