5 ms·
REST is one of those things were if you don't implement all of it, you won't really reap the benefits of all those architectural constraints combined. In your D
by jalfresi 11y ago
REST is one of those things were if you don't implement all of it, you won't really reap the benefits of all those architectural constraints combined. In your Dropbox example, any client will be bound to the Dropbox API. Consequently, Dropbox are now bound to each and everyone of those clients; they cannot make changes on the server side without breaking every client. This is what REST aims to provide - a safe way for the server to change as needed without breaking clients.
Imagine if Dropbox registered a set of mime-types for each of the different resource representations. Those mime-type RFCs would describe how clients interpret the representations whilst simutainiously giving Dropbox the ability to change the server as they need without fear of breaking clients.
This would be because clients would be foxing on how to process the media-types, not the API. The various interactions a client can make with a representation (regardless of the URL it came from) would be bound to the media-type e.g. rel-types for edit, upload, create etc which the RFC would describe the appropriate HTTP interactions e.g. POST a media-type of x to the url at rel-type "edit".
However, I think the real reason that REST hasn't been adopted fully is that service providers like Dropbox have found that there advantages to binding client developers to their hardcoded APIs; the last thing Dropbox wants (and what REST would provide) is a standardised set of media-types and RFCs describing the interactions for a standardised way of interacting with an external cloud-based storage provider.
It's just another form of lock-in, and reminded the cynic in me of the bad old days of MS Office document lock-in.
- drrogers 11y agoumm, 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 agoWhilst 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 agoNot 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 agoIf 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 agoHow 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 agoNo, 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.
- aikah 11y ago> However, I think the real reason that REST hasn't been adopted fully is that service providers like Dropbox have found that there advantages to binding client developers to their hardcoded APIs; the last thing Dropbox wants (and what REST would provide) is a standardised set of media-types and RFCs describing the interactions for a standardised way of interacting with an external cloud-based storage provider. I'd argue it's not a problem if a vendor can generate clients for his API. I'd also argue that most clients break with each API version anyway, because of the way developers code them.