But is this a formal,normative spec or a dissertation ? because that's the main reason why nobody understand what REST is, because there is no paper about REST that is written in a formal way like spec should. If REST had clear and precise rules,then there would be a reference that acts as an authority.
It's an architectural style. It's not something that's formal. Like MVC[1] or a style of constructing buildings.
I'm not sure why anyone would want anything more formal than the dissertation or mvc notes -- it's just some (good) ideas. Maybe the fact that they have their own acronym confuses people?
[Ed: I suppose WebDAV[2] could be considered a formalisation ... but again representional state transfer is derived from the unique demands/constraints of hypertext information systems; it's not a good fit for db systems. That doesn't change just because you deploy the front-end in a web browser...]
> It's an architectural style. It's not something that's formal.
There lies the problem, some people still say that it something IS formal(thus they think they speak out of authority) Truth is,nobody has a fn clue what REST really is aside from its "creator", I still don't know myself and trust me , I read the original paper.
The problem is also that people oppose REST and XML-RPC when in fact XML-RPC IS a protocol,when REST is not. REST never ever said what a resource should look like, nor what a URL should look like. Strange for something that is supposed to replace SOAP ? (and i'm not a fan of SOAP )
The lack of formalism of REST has done a great deal of damage IMHO(One client per api...), so much than people are now reverting to SOAP like protocols ( like GraphQL , a unique client per language).
But is this a formal,normative spec or a dissertation ? because that's the main reason why nobody understand what REST is, because there is no paper about REST that is written in a formal way like spec should. If REST had clear and precise rules,then there would be a reference that acts as an authority.