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 addition (I don't know who made this), and that is OK. If it is not present in the beginning, I assume that the complement 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)  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.
What distinguishes HTTP from RPC isn't the syntax. It isn't even the different characteristics gained from using a stream as a parameter, though that helps to explain why existing RPC mechanisms were not usable for the Web. What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services. The result is an application that allows for layers of transformation and indirection that are independent of the information origin, which is very useful for an Internet-scale, multi-organization, anarchically scalable information system. RPC mechanisms, in contrast, are defined in terms of language APIs, not network-based applications.
The question is, am I wrong, or has something wrong with the "archetype controller"?