4 ms·

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

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 https://www.dropbox.com/developers-v1/core/docs)

jalfresi 11y ago
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).
gkop 11y ago
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.
icebraining 11y ago
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_af 11y ago
  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?
  - icebraining 11y ago
    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.
    - the_af 11y ago
      > 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.
      - steveklabnik 11y ago
        It's not more complex, it's just different. Constructing URLs is more complex than just following them, for example.
- detaro 11y ago
  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.
AReallyGoodName 11y ago
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).
- e12e 11y ago
  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.ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.webdav.org/specs/ http://www.webdav.org/specs/
  - AReallyGoodName 11y ago
    WebDav dates back to 1996. You've just got a list of the latest rfcs. https://tools.ietf.org/html/rfc2518 https://tools.ietf.org/html/rfc2518
- drrogers 11y ago
  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.
JimDabell 11y ago
> 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.
e12e 11y ago
> 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.
mavelikara 11y ago
> 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/ http://jackrabbit.apache.org/

jalfresi 11y ago

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).

gkop 11y ago

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.

icebraining 11y ago

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_af 11y ago
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?
- icebraining 11y ago
  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.
  - the_af 11y ago
    > 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.
    - steveklabnik 11y ago
      It's not more complex, it's just different. Constructing URLs is more complex than just following them, for example.
detaro 11y ago
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.

AReallyGoodName 11y ago

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).

e12e 11y ago
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.ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.webdav.org/specs/ http://www.webdav.org/specs/
- AReallyGoodName 11y ago
  WebDav dates back to 1996. You've just got a list of the latest rfcs. https://tools.ietf.org/html/rfc2518 https://tools.ietf.org/html/rfc2518
drrogers 11y ago
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.

JimDabell 11y ago

> 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.

e12e 11y ago

> 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.

mavelikara 11y ago

> 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/ http://jackrabbit.apache.org/