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 - 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.
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!
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).
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.
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.
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.
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.
[+] [-] danpalmer|11 years ago|reply
However, it doesn't appear anywhere near "fully" RESTful as described. The docs even link to 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.
[+] [-] pearkes|11 years ago|reply
If you're in need of a Ruby client, check out 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
[+] [-] andrewsomething|11 years ago|reply
We're trying to collect clients using APIv2 over on the community site. Barge is already listed:
https://www.digitalocean.com/community/questions/what-librar...
[+] [-] yoda_sl|11 years ago|reply
[+] [-] philip1209|11 years ago|reply
[+] [-] opendais|11 years ago|reply
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.
[+] [-] netcraft|11 years ago|reply
[+] [-] SEJeff|11 years ago|reply
http://brianketelsen.com/2014/02/25/using-nginx-confd-and-do...
[+] [-] danielsamuels|11 years ago|reply
[+] [-] progrium|11 years ago|reply
[+] [-] SEJeff|11 years ago|reply
[+] [-] progrium|11 years ago|reply
[+] [-] pestaa|11 years ago|reply
This is a legitim question that opens up a great topic about protocol support.
[+] [-] bcohen123|11 years ago|reply