So what REST really boils down to, versus the next best thing, is creating file types instead of protocols/APIs. And its value is based on the presumption that file types will be more stable and versatile, and less coupled to any particular service.
While I would agree with that, I question how often a developer actually has a choice of whether or not to go with REST. It seems to solve an entirely different problem than an API: REST is for public standards, not proprietary services. You certainly need to know which you are making before you worry about what architecture to use.
If the Twitter API were RESTful, it would be OStatus, and that's obviously not what it's supposed to be.
> Why could you not use REST for proprietary services?
Proprietary services can be entirely controlled: proprietary server, proprietary client, proprietary protocol. You don't mind if they are coupled, just update them at the same time. Also, proprietary protocol often don't come with the long term vision that characterize open file formats and protocols. The cash has to flow soon, then for a few years. Beyond that, all bets are off.
So it's not that you couldn't, but rather that you wouldn't. I guess.
Of course you do. They may be under the control or purview of different team members (or teams, or contractors), and coupling always increases maintenance costs.
> just update them at the same time.
Or don't couple them and update them when you need to.
> Also, proprietary protocol often don't come with the long term vision that characterize open file formats and protocols. The cash has to flow soon, then for a few years. Beyond that, all bets are off.
Right, so you would not use REST for proprietary services because proprietary services are by definition moronic in design and intent?
Not moronic, just smaller in scope. Media types require considerably more work to design than APIs, as is often noted by REST proponents. The guy who invented REST calls it "engineering on the scale of decades". If You Ain't Gonna Need That then you're wasting a lot of time by doing it that way.
Yeah, if Twitter were RESTful the client would not be reliant on server state to function. And the media type would have to be documented and adhered to. Meaning e.g. that multiple vendors could be used simultaneously without conflict.
Being RESTful would just increase interoperability. But that's not Twitters game.
While I would agree with that, I question how often a developer actually has a choice of whether or not to go with REST. It seems to solve an entirely different problem than an API: REST is for public standards, not proprietary services. You certainly need to know which you are making before you worry about what architecture to use.
If the Twitter API were RESTful, it would be OStatus, and that's obviously not what it's supposed to be.