Richard Wackerbarth writes:
I think that you are finally beginning to understand the perspective that I am trying to provide.
I don't have any trouble understanding the perspective you're trying to provide in the abstract; it's just Software Systems Design 301.
What I have trouble seeing is why you want to go to this level of abstraction for Mailman 3, and what implications is has for design and implementation of Mailman services.
Yes, to implement anything, we will need the concrete descriptions at the protocol level.
But AIUI, REST isn't a concrete description. Wikipedia, for example, calls it an "architectural style". Specifically, that article defines it as a service meeting 5 constraints (and there's an optional 6th).[1] If your abstract service doesn't satisfy those constraints, then it can't be implemented RESTfully, which in turn constrains implementer designs (eg, it means changing multiple modules to implement a new service).
So for this purpose, I see the HTTP verbs used in REST, such as GET, as being primitives obeying certain constraints, but not as necessarily implemented by trivial references to the concrete HTTP implementation. Similarly, the REST approach to addressing resources via URLs puts some constraints on the structure of Mailman's data. IOW, REST is a language for describing interactions among Mailman components, not a specific implementation of such interactions.
Specifically, one interface may provide multiple implementations which accomplish the same system service. (Many ways to skin the cat) Alternate implementations are required to provide just one of them.
I don't understand. How is one component that speaks REST supposed to communicate with another specified in terms of the ZCA? They satisfy different constraints.
Footnotes: [1] http://en.wikipedia.org/wiki/REST