Instead of fetishizing REST for its own sake, how about appreciating an HTTP API that can be used (read/written) with a browser via form elements and hrefs?
This can be done on top of REST API with your server acting as a client to your own API. Actually, that way it'll probably be possible to implement it much safer.
And what's the use case anyway? Are you going to perform those requests from other domains and authenticating via cookies on your own? How do you protect from CSRF doing that? What's wrong with OAuth 2.0 + JS?
I completely agree with you. There will always be a contingent of developers who believe enforced standards trump simplicity. As we see here, when the CORBA then SOAP crowd realized they'd lost that fight, their ilk started judging other projects by adherence to strict API structural definitions like formal "REST". That said, I do believe this constant dialog between ad-hoc simplicity and rigid standards is good for the industry; in each area, accepted practice evolves to meet the needs of its current application.
REST is as simple as it gets. You could make that argument if someone were to advocate using REST outside of HTTP. But HTTP is inherently REST, so you should have a good reason to not use REST rather than the other way around.
It is not. It's quite complex actually. And I'm betting what most people who believe they have a clue think of "REST" is actually "RPC over pretty urls".
But that's just because of a general ignorance of how HTTP protocol works. If someone were to be explained, how it should work from the beginning, I'm sure they'd have no problem with grasping the subject.
Actually some Google engineers do a very good job of explaining how AtomPub and GData APIs work just with short Youtube videos.
