api design – Is the “archetype controller” really complies with REST architectural style

I’ve read the Fielding’s thesis that defines the REST architectural style and noticed that the defined style appears to significantly conflicts with the so called “archetype controller”, that a definition can be found in many places, like here.

The first thing to highlight here is that the “resources archetypes” is not present in the original thesis, it was a later addiction (I don’t know who made this), and that is OK. But if it is not present in the beginning, then that the compliment of this resource style is not part of the REST constraints.

But the issue here is that it seems to mismatch with what Fielding originally wrote about this:

Any information that can be named can be a resource: a document or image, a temporal service (e.g. “today’s weather in Los Angeles”), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.


The “archetype controller” seems to be a kind of a Remote Procedure Call. Not when he was talking about REST, but about HTTP, he also made the observation that HTTP is not RPC:

People often mistakenly refer to HTTP as a remote procedure call (RPC) (23) mechanism simply because it involves requests and responses. What distinguishes RPC from other forms of network-based application communication is the notion of invoking a procedure on the remote machine, wherein the protocol identifies the procedure and passes it a fixed set of parameters, and then waits for the answer to be supplied within a return message using the same interface.


The question is, am I wrong, or has something wrong with the “archetype controller”?