> 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.
And hypermedia as the application state driver. That's actually the main component of a restful API, though the one most often missed.
> It seems to solve an entirely different problem than an API: REST is for public standards, not proprietary services.
Why could you not use REST for proprietary services?