Hacker News Reader

Comment by drrogers | Hacker News Reader

umm, can you cite a RESTful cloud storage API that's consistently implemented between providers? If Dropbox's API was RESTful would that save me any time using Google's competing API? By the way, all these platform provide SDKs for you anyway and that's usually a better way to use them.

When you start playing with the APIs from lots of different cloud storage folks (Dropbox, OneDrive, Google Drive) you see that they vary widely in concepts and capabilities. REST or not building a client for one doesn't really make you closer to using another. Also Dropbox's old API was REST and it doesn't seem more portable (https://www.dropbox.com/developers-v1/core/docs)

View on HN

> can you cite a RESTful cloud storage API that's consistently implemented between providers?

It's been a while since I've worked with it, but IIRC, WebDAV is one example.

> Dropbox's old API was REST

That's not REST. It's that weird anti-REST where people define URI patterns instead of media types. I don't know why it became trendy to label things like that REST, but they aren't.

If Dropbox's API was RESTful would that save me any time using Google's competing API?

If Dropbox's API was RESTful, you'd be able to use Google by only switching the initial URL - which could even be configurable by the user, or auto-discovered from the website.

When you start playing with the APIs from lots of different cloud storage folks (Dropbox, OneDrive, Google Drive) you see that they vary widely in concepts and capabilities.

They don't vary _widely_ in concepts and capabilities, they add a layer on top of the same concepts (files, directories, upload/download, get public URL), and REST allows you to support generic and specific clients easily, by either using extensible or multiple media types.

Also Dropbox's old API was REST and it doesn't seem more portable

It resembled REST, but it wasn't. A good way to tell: if you need a documentation page with a list of all the URLs you can call, it's probably not RESTful.

The claim "just change the base URL and everything works" always seemed unrealistic to me. The relation names, the understood data-types, ... still have to be compatible, and IMHO that is the point where things would fail.

Those are the media types, which should be standard or at least reusable by others. The difficulty is not technical, it's economics: everyone wants to lock in their users, and this goes against that wish.

When the conditions are right, you do see this: RSS/Atom is a good example.

It is technical.

Show me a general purpose program that can navigate, interpret and comprehend a variety of media types and I will show you an AI.

It navigates the media types it has been programmed to handle. What part of that requires AI?

Why is that that much better than navigating the fixed relative URLs of a non-REST a client has been programmed to try?

Some advantages: https://blogs.oracle.com/craigmcc/entry/why_hateoas

But what I really see as the main advantage is the decoupling of server and UI, kind of like Android Intents on steroids. By using standard formats and dynamic routes between them, the user is no longer tied to a silo with a window through which they can interact with their data; they can know use his own chosen software to handle the different types of information, jumping through them as needed, without ever being locked-in to a particular provider.

And for the developers, why are we building the same crap again and again using the API du-jure, when 90% of it uses the same concepts as existing software? Why do we need thousands of libraries and middleware that provides a "single API to many services"? We spend so much effort building these rickety integrations, just because the providers insist on using different names for the same things.

Doesn't it abhor you, the waste of it all?

The issue is that most vendors don't want to converge on a standard. Stuff would be fine if that standard wasn't properly RESTful, as long as it was a standard, but many arguments towards RESTful IMHO present the benefits we would get from any standard as the benefits we would (only) get from a RESTful standard.

I agree that the current situation is crappy. I agree that HATEOAS/REST ideas implemented properly and with the intend to cooperate would help a lot, and that there are many worse candidates for a standard.

I disagree that HATEOAS/REST would matter that much, compared to the "implemented properly and with the intend to cooperate".

How many APIs (and corresponding clients) do you know where "only switching the initial URL" is enough? I don't know many. Doesn't this require incredibly complex clients?

No, it doesn't require complex clients. There aren't many examples because (1) most developers don't even understand the concept and (2) it reduces lock-in, which most providers aren't interested in supporting.

> No, it doesn't require complex clients

You really don't think that a flexible client which is able to discover resources and actions based only on an initial URL is more complex than one which is more hardcoded to a specific implementation and resources? I must be missing something, because to me, it obviously is.

The obvious example of the Web and web browsers is not entirely convincing to me. Yes, browsers are flexible, but at the same time, the Web is an incredibly specific example. There are "hardcoded" expectations of what a web browser must be able to do, that I simply don't see in more general examples and use cases. And whenever we want to do something out of the ordinary with a web browser (I know, I know, "web browsers were never meant for that!") this general model of the web breaks down and we stray into wildly incompatible and hacky ways of doing things.

It's not more complex, it's just different. Constructing URLs is more complex than just following them, for example.

bingo! same thing I said in 2012 https://www.youtube.com/watch?v=Nh6VeuvVRdQ . Depressing that time passes, and nothing really changes.

Webdav predates REST but it essentially ticks all of the boxes that make up REST. Plenty of providers offer Webdav cloud storage (basically all of the smaller ones since they can't really afford to maintain their own API).

It does? The REST thesis came out in 2000, looks like the (and AFAIR) WebDAV came later?

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

http://www.webdav.org/specs/

WebDav dates back to 1996. You've just got a list of the latest rfcs.

https://tools.ietf.org/html/rfc2518

I wonder why all the larger ones don't support it.

Also the existence of WebDAV doesn't really demonstrate that merely adhering to REST will make your clients portable.

Whilst I can't provide you an example for cloud storage, I can for syndicated feeds. ATOM is an example of multiple clients interacting with separate syndicated feed servers. The individual implementations can all differ.

The way a client interacts with the server is via the media-type and HATEOAS (via the rel-types).

> umm, can you cite a RESTful cloud storage API that's consistently implemented between providers?

WebDAV? You can get pretty far with eg davfs and Plone/Zope -- and you can also mix and match servers and clients. Now, lots of WebDAV clients and servers are broken in many sad ways... but it exists.

> mm, can you cite a RESTful cloud storage API that's consistently implemented between providers

Fielding worked at Day Software, which made a web content management system. They contributed parts of their system to the community as Apache Jackrabbit [1] before getting acquired by Adobe.

Not sure if Day Software's APIs match your asks though.

[1] http://jackrabbit.apache.org/

Not RESTful per se (though certainly not un-RESTful, either) but a number of vendors support a healthy subset of the S3 API such that the vendors may be interchangeable for your application.

Reply on news.ycombinator.com