> To me there seems to be an abstraction leak. Specifically he's baked HTML into his entire thesis.
No he's not, he's baked hyperlinks into his thesis as the base of REST, that has nothing to do with HTML.
> One of his goals was that a document would be able to provide links to another document in a natural, intuitive way.
No. His goal is merely that documents be hyperlinked, how is the application's domain.
> It is ment to be so intuitive in fact that the interchange of the document doesn't need a schema or WSDL like system.
I don't know where you got that one, but it's definitely not part of Fielding's thesis or his comments on the subject since. It's in fact exactly the opposite, the one thing Fielding notes must be documented in details in a RESTful service is media types, aka the documents returned by the service. That's where hyperlink semantics are added.
> JSON however doesn't.
Neither does SGML or XML, that's not an issue.
> If one wants to nest links in JSON, one has to tell the client how those links will appear.
Just as one has done with HTML.
> On has to define the structure beyond merely syntaxical correctness.
Just as with HTML.
> This is where REST falls down, IMHO.
That's complete and utter nonsense.
The only difference between HTML and JSON is that HTML is already an application of a meta-document type (well used to be, of SGML, it's drifted further but conceptually it still is) whereas JSON, much like XML, is a meta-document type from which users build applications (what do you think application/xhtml+xml is?).
You sound like you want some magical silver-bullet through which you don't have to document anything and things suddenly understand each others based on fairy dust. Reality does not work that way.
No he's not, he's baked hyperlinks into his thesis as the base of REST, that has nothing to do with HTML.
> One of his goals was that a document would be able to provide links to another document in a natural, intuitive way.
No. His goal is merely that documents be hyperlinked, how is the application's domain.
> It is ment to be so intuitive in fact that the interchange of the document doesn't need a schema or WSDL like system.
I don't know where you got that one, but it's definitely not part of Fielding's thesis or his comments on the subject since. It's in fact exactly the opposite, the one thing Fielding notes must be documented in details in a RESTful service is media types, aka the documents returned by the service. That's where hyperlink semantics are added.
> JSON however doesn't.
Neither does SGML or XML, that's not an issue.
> If one wants to nest links in JSON, one has to tell the client how those links will appear.
Just as one has done with HTML.
> On has to define the structure beyond merely syntaxical correctness.
Just as with HTML.
> This is where REST falls down, IMHO.
That's complete and utter nonsense.
The only difference between HTML and JSON is that HTML is already an application of a meta-document type (well used to be, of SGML, it's drifted further but conceptually it still is) whereas JSON, much like XML, is a meta-document type from which users build applications (what do you think application/xhtml+xml is?).
You sound like you want some magical silver-bullet through which you don't have to document anything and things suddenly understand each others based on fairy dust. Reality does not work that way.