The prototypical example of a REST API is a web application. They use a standard content type (HTML or XHTML), hypertext to link resources, and typically don't require any out-of-band technical information to work.
Right, that makes sense. But I guess I don't really understand how that moves the conversation forward.
Maybe I misread your original comment, but it sounded to me like you were claiming that there are a whole buncha crappy REST APIs out there that are no better than the crappy XML-RPC/SOAP APIs of yore, and that there would be a whole new world of coolness if only they stayed true to the REST protocol.
Saying, "oh, it's just the web," is just another variation of the obscurity in Fielding's post that tptacek is complaining about in his comment.
Anyhow, it's not like you have some responsibility to justify REST to me or anything, but I'm as yet unconvinced of what this gap between "true" and "pretend" REST APIs really is, and what benefits lie for everyone in close that gap.
EDIT: Just saw your "translation" of that Fielding post in reply to tptacek's comment, which was quite helpful.
I'm not claiming that XML-RPC or SOAP is "crappy"; there might be poorly-designed implementations (and of REST also!), but both have vital and important use cases. I have never used SOAP, but have both designed and consumed many XML-RPC APIs, and have no problem with them.
It's very important to use accurate terminology when discussing software and technology. The statement "Foo.com uses a REST API" only contains useful information if 'REST' is meaningfully defined. If 'REST' is redefined as a synonym for 'XML-RPC', then we lose the ability to distinguish between a REST and XML-RPC API in written or spoken conversation. I am not making any value judgment regarding either API style; they are simply different, and should be kept distinct for the purposes of communication.
