6 ms·

DigitalOcean API v2.0 Enters Public Beta

66 points by beigeotter 12y ago

yoda_sl 12y ago
Great to see an API improvement for DO! But at the same time, I wish they will provide a few more base features (at a price of course) like an equivalent of S3, EBS and load balancing. With at least those services in place, I will most likely start moving a few apps on DO (yes I know I can use S3 but you get the idea).
- opendais 12y ago
  Tbh, given DO's price point, I think EBS would be more support headache than its worth. Cloudfront & S3 [or equiv] you can already get elsewhere and it doesn't really impact the setup. DO really, really badly needs highly available, multi-datacenter load balancers. Without highly available load balancing [even in-DC would be good enough] where you can failover the IPs from Load Balancer A to B... I just don't see it moving outside of the hobby/staging/etc space. Projects that you can afford downtime on.
  - nmjohn 12y ago
    I have a handful of sites that are more than just hobby sites, but the number of 9's in the SLA won't affect the bottom line at all. 5 DO droplets = $25 / month makes significantly more sense in this case than paying over $150 for the equivalent at AWS. And I think this use is a large enough market for DO to make a fortune.
    - opendais 12y ago
      Fair enough. I've never worked on that sort of thing so to me downtime == $$ lost. I need a load balancer for anything more than a hobby project as a result. The one thing I can't find anywhere is truly multi-DC load balancers as a service from a hosting provider I'd use.
    - bryanlarsen 12y ago
      Sure, but I'm willing to bet that if DO offered failover, you'd be willing to pay them more to take advantage of it. Perhaps not a lot more, but it's money they're leaving on the table. I do think that offering IP failover would be a much better way for DO to pick up extra revenue in the future than offering a competitor to S3 or EBS or Cloudfront or whatever.
  - JuiceSSH 12y ago
    If you can survive a few minutes downtime, then you can use Amazon Route53 failover DNS (with health checks) combined with low TTLs to provide failover between DigitalOcean data centres for ~$0.50/month - this is how we structure our less critical APIs that are hosted there. I agree though - it'd be great if DO provided a proper load balancing solution.
    - opendais 12y ago
      Mhm, I can do DNS load balancing now with any provider. DO's main competition atm with price parity is Linode which provides single-dc HA load balancers. If I want to pay more I can use AWS, GCP, Azure, etc that also offer them. ;) I'd really like to avoid DNS load balancing to failover within a datacenter at a minimum [in the event of a load balancer failure], ideally I'd like to avoid it completely.
- netcraft 12y ago
  I've had the same thought before, but I worry more and more about vendor lock in. I like DO because theyre just giving me a server - I can implement a proxy or a database or whatever on them the same as I would on any VPS. For me to use a service like s3 from DO it would have to have basically the same API as s3 or some other service I could switch to if necessary.
  - _delirium 12y ago
    I agree as far as lock-in goes, but there are some fairly simple "cloudy" things that don't really require lockin. One thing I miss at DO is just being able to set up network-attached storage, e.g. an 100GB drive that I can NFS-mount on a droplet. Instead the only storage available is the instance storage.
- philip1209 12y ago
  Frankly, S3 is awesome as it is - I would appreciate it if there was direct connect between DO and AWS.
- SEJeff 12y ago
  You might be surprised to know that haproxy or nginx in a container with confd + etcd is actually quite trivial to setup for load balancing: http://brianketelsen.com/2014/02/25/using-nginx-confd-and-docker-for-zero-downtime-web-updates/ http://brianketelsen.com/2014/02/25/using-nginx-confd-and-do...
pearkes 12y ago
The v2 API is a huge improvement, great work! If you're in need of a Ruby client, check out barge: https://github.com/boats/barge https://github.com/boats/barge. Additionally, Tugboat[1] will be moving from my github account over to the 'boats' org and using the new API. If you're interested in helping with an existing project (such as Tugboat or Barge), or a new one, please let me know! [1]: https://github.com/pearkes/tugboat https://github.com/pearkes/tugboat
- andrewsomething 12y ago
  Tugboat is a great tool! We're trying to collect clients using APIv2 over on the community site. Barge is already listed: https://www.digitalocean.com/community/questions/what-libraries-and-wrappers-are-there-for-digitalocean-s-apiv2 https://www.digitalocean.com/community/questions/what-librar...
danielsamuels 12y ago
I just wish there was a way of letting multiple people log into the same account without sharing credentials.
- progrium 12y ago
  You can generate personal OAuth tokens and let them use the API.
SEJeff 12y ago
No HTTP PATCH support? Makes me a sad panda. PATCH > PUT.
- progrium 12y ago
  It originally had PATCH in the design. I think it was a limitation of our tooling that made us reconsider. And that PUT was slightly more familiar for novice users. At the end of the day ... it doesn't matter. Either way is a huge improvement from all GET.
  - SEJeff 12y ago
    Totally agreed, but for us that also write and consume RESTful services, PATCH is the best way to prevent race conditions when you have multiple things updating at the same time. That and as a purist, I like the idea of updating the minimal amount vs the entire object all at once. Regardless, this is a HUGE improvement, so nice work! Oh and please keep the interesting projects coming on github. I'm a fan of the docker + consul integration you've been working on.
- pestaa 12y ago
  I completely don't understand downvotes lately. Is it the joke? Or the use of a relation symbol instead of in-depth analysis of the pros and cons? This is a legitim question that opens up a great topic about protocol support.
danpalmer 12y ago
This looks like a really nicely designed API when compared to many others, good job team! However, it doesn't appear anywhere near "fully" RESTful as described. The docs even link to http://en.wikipedia.org/wiki/Representational_state_transfer http://en.wikipedia.org/wiki/Representational_state_transfer - but I can't see any HATEOAS style support in there (only looking at the docs, I haven't started actually using the API yet). I realise this is a topic that gets brought up again and again, I have done this myself several times, but I don't think we're going to see a paradigm shift in ease of use of APIs, or in how consumers of APIs work, until lots of API providers are supporting HATEOAS. Sure, it's not very well defined yet, but it will become better defined with each provider that implements it and builds on what others are doing.
bcohen123 12y ago
Good! Looks good and was a MUCH needed update. Their last version was a tad....unusable at times and lacked some much needed features. Glad to see an upgrade.

66 points by beigeotter 12y ago

Great to see an API improvement for DO! But at the same time, I wish they will provide a few more base features (at a price of course) like an equivalent of S3, EBS and load balancing. With at least those services in place, I will most likely start moving a few apps on DO (yes I know I can use S3 but you get the idea).

opendais 12y ago
Tbh, given DO's price point, I think EBS would be more support headache than its worth. Cloudfront & S3 [or equiv] you can already get elsewhere and it doesn't really impact the setup. DO really, really badly needs highly available, multi-datacenter load balancers. Without highly available load balancing [even in-DC would be good enough] where you can failover the IPs from Load Balancer A to B... I just don't see it moving outside of the hobby/staging/etc space. Projects that you can afford downtime on.
- nmjohn 12y ago
  I have a handful of sites that are more than just hobby sites, but the number of 9's in the SLA won't affect the bottom line at all. 5 DO droplets = $25 / month makes significantly more sense in this case than paying over $150 for the equivalent at AWS. And I think this use is a large enough market for DO to make a fortune.
  - opendais 12y ago
    Fair enough. I've never worked on that sort of thing so to me downtime == $$ lost. I need a load balancer for anything more than a hobby project as a result. The one thing I can't find anywhere is truly multi-DC load balancers as a service from a hosting provider I'd use.
  - bryanlarsen 12y ago
    Sure, but I'm willing to bet that if DO offered failover, you'd be willing to pay them more to take advantage of it. Perhaps not a lot more, but it's money they're leaving on the table. I do think that offering IP failover would be a much better way for DO to pick up extra revenue in the future than offering a competitor to S3 or EBS or Cloudfront or whatever.
- JuiceSSH 12y ago
  If you can survive a few minutes downtime, then you can use Amazon Route53 failover DNS (with health checks) combined with low TTLs to provide failover between DigitalOcean data centres for ~$0.50/month - this is how we structure our less critical APIs that are hosted there. I agree though - it'd be great if DO provided a proper load balancing solution.
  - opendais 12y ago
    Mhm, I can do DNS load balancing now with any provider. DO's main competition atm with price parity is Linode which provides single-dc HA load balancers. If I want to pay more I can use AWS, GCP, Azure, etc that also offer them. ;) I'd really like to avoid DNS load balancing to failover within a datacenter at a minimum [in the event of a load balancer failure], ideally I'd like to avoid it completely.
netcraft 12y ago
I've had the same thought before, but I worry more and more about vendor lock in. I like DO because theyre just giving me a server - I can implement a proxy or a database or whatever on them the same as I would on any VPS. For me to use a service like s3 from DO it would have to have basically the same API as s3 or some other service I could switch to if necessary.
- _delirium 12y ago
  I agree as far as lock-in goes, but there are some fairly simple "cloudy" things that don't really require lockin. One thing I miss at DO is just being able to set up network-attached storage, e.g. an 100GB drive that I can NFS-mount on a droplet. Instead the only storage available is the instance storage.
philip1209 12y ago
Frankly, S3 is awesome as it is - I would appreciate it if there was direct connect between DO and AWS.
SEJeff 12y ago
You might be surprised to know that haproxy or nginx in a container with confd + etcd is actually quite trivial to setup for load balancing: http://brianketelsen.com/2014/02/25/using-nginx-confd-and-docker-for-zero-downtime-web-updates/ http://brianketelsen.com/2014/02/25/using-nginx-confd-and-do...

pearkes 12y ago

The v2 API is a huge improvement, great work! If you're in need of a Ruby client, check out barge: https://github.com/boats/barge https://github.com/boats/barge. Additionally, Tugboat[1] will be moving from my github account over to the 'boats' org and using the new API. If you're interested in helping with an existing project (such as Tugboat or Barge), or a new one, please let me know! [1]: https://github.com/pearkes/tugboat https://github.com/pearkes/tugboat

andrewsomething 12y ago
Tugboat is a great tool! We're trying to collect clients using APIv2 over on the community site. Barge is already listed: https://www.digitalocean.com/community/questions/what-libraries-and-wrappers-are-there-for-digitalocean-s-apiv2 https://www.digitalocean.com/community/questions/what-librar...

danielsamuels 12y ago

I just wish there was a way of letting multiple people log into the same account without sharing credentials.

progrium 12y ago
You can generate personal OAuth tokens and let them use the API.

SEJeff 12y ago

No HTTP PATCH support? Makes me a sad panda. PATCH > PUT.

progrium 12y ago
It originally had PATCH in the design. I think it was a limitation of our tooling that made us reconsider. And that PUT was slightly more familiar for novice users. At the end of the day ... it doesn't matter. Either way is a huge improvement from all GET.
- SEJeff 12y ago
  Totally agreed, but for us that also write and consume RESTful services, PATCH is the best way to prevent race conditions when you have multiple things updating at the same time. That and as a purist, I like the idea of updating the minimal amount vs the entire object all at once. Regardless, this is a HUGE improvement, so nice work! Oh and please keep the interesting projects coming on github. I'm a fan of the docker + consul integration you've been working on.
pestaa 12y ago
I completely don't understand downvotes lately. Is it the joke? Or the use of a relation symbol instead of in-depth analysis of the pros and cons? This is a legitim question that opens up a great topic about protocol support.

danpalmer 12y ago

This looks like a really nicely designed API when compared to many others, good job team! However, it doesn't appear anywhere near "fully" RESTful as described. The docs even link to http://en.wikipedia.org/wiki/Representational_state_transfer http://en.wikipedia.org/wiki/Representational_state_transfer - but I can't see any HATEOAS style support in there (only looking at the docs, I haven't started actually using the API yet). I realise this is a topic that gets brought up again and again, I have done this myself several times, but I don't think we're going to see a paradigm shift in ease of use of APIs, or in how consumers of APIs work, until lots of API providers are supporting HATEOAS. Sure, it's not very well defined yet, but it will become better defined with each provider that implements it and builds on what others are doing.

bcohen123 12y ago

Good! Looks good and was a MUCH needed update. Their last version was a tad....unusable at times and lacked some much needed features. Glad to see an upgrade.