As I watch the REST versus non-REST discussion, it occurs to me that there are a number of aspects to the debate. While I am not attempting to address all of these aspects, I think that part of the discussion revolves around DATA versus BEHAVIOR.
When people talk about CRUD (Create, Read, Update, and Delete) interfaces, on the surface, they are manipulating data. Sometimes, this implicitly causes behavior. This is a long-standing pattern that I certainly know has gone on for decades…
So, let’s apply some nomenclature:
- Nouns: These are data items which get manipulated via CRUD (or equivalent) interfaces.
- Verbs: This is behavior which is implemented with a method call or some equivalent.
Now, of course, method calls get marshaled… Hmm… Is the marshaled method call a noun or a verb?
OK, let’s speak about the programmatic abstraction visible to the caller… Is it a method call or is it a CRUD operation? What about the methods “Set” and “Get”? Those are obviously method calls. But their soul is to set and get property values and, hence, are really pretty CRUDdy! Gee, verbs can be nouned!
But let’s look at verbing the nouns (rather than nouning the verbs).
Example-1 of Verbing a Noun: the Multi-Master Behavior-Turd
A common pattern I have seen when using multi-master database replication across occasionally connected systems is a hub-and-spoke model. The spoke systems will write a record in the database with a unique key (typically based on the spoke’s system identity to ensure uniqueness). The semantic meaning of this little record (the “behavior-turd”) is a request to perform work at the hub and ship down the answer in the replicated database.
The behavior-turd remains in the offline database until the system can reconnect. When the systems connect, the behavior-turd is replicated to the hub which fires a trigger. Work is done on the hub and the results of this work replicate their way back to the spoke (and all of the other spokes, too).
Important to this approach is the separation of the location in the database for the behavior-turds (basically the messaging mechanism) from the other data updated by the hub and read by the spokes. So the behavior-turds are nouns which act as verbs. Definitely a case of verbing a noun.
Example-2 of Verbing a Noun: CRUDing on the Purchase-Order
So, let’s consider a purchase-order data structure. As the purchaser (or software representing the purchaser) adds line-items to the purchase-order, that will cause behavior in the back-end system. Is the purchase-order (or even the line-item) a noun or a verb? I would argue is it syntactically a noun but semantically a verb.
This happens ALL the time. A form is filled out and that implies work to do… Seems like behavior to me even if the localized action of the invoker is to manipulate some data!
Private (and Encapsulated) Data versus Public (Interfacey) Data
It is important to look at the purpose and use of the “data”. When we abstract all data as being equivalent, we miss out on a lot of underlying complexity. The internal inventory balance (which may change every few seconds) is certainly not updatable by outside services. We can’t assume that CRUD across boundaries carries the evil of CRUD (at a distance) over internal (i.e. private and encapsulated) data.
It has always been my inclination to model the encapsulated behavior as, well, behavior. There’s a lot of evidence of successful applications that model the invocation of their behavior as CRUDdy manipulation of some externally updatable data. This is just the same as paper forms in the (before computers) normal business models. Fill out the piece of paper and hand it to the person behind the desk. Filling out the piece of paper is a CRUD operation on the data of the paper. Handing over the piece of paper causes the semantic invocation of some behavior provided by the business.
Natural Selection and Usage of Primitives
There seems to be a gravitation towards simple primitives even if the usage of these simple primitives creates a lot of complexity over time. OK… I can dig that. Back in the mid-90s, I was heavily arguing for early binding (as manifested in COM). The use of early binding drove crisp and clear semantics; goodness, light, and moral rectitude. IDispatch was clearly too fuzzy in its semantics for grown ups…
Well… I admit I was wrong! The ability to use late binding and tooling to adaptively “do the right thing” dominated the lack of crispness in the semantics. Indeed, the crispness wasn’t really crispness but it was brittleness. People LIKED the late binding of IDispatch and made it work.
So, in my new state of late-life Zen, I’m not about to fuss about the use of NOUNS rather than VERBS… Just make sure you interpret the durn’ things with the correct semantics and I’ll loosen up over the syntax of your invocation.
In fact, I’ll go so far as to say that the usage of data (NOUNS) to invoke distant behavior (VERBS) might just be a dandy thing. It may be easier to do transformations, filtering, and other mashup-esque whacking on the intended behavior.
It occurs to me that we are seeing both:
- The natural selection of mechanisms used to knit together our services (or apps or systems), AND
- The natural selection of the implementers who either:
- adapt to the new world order with its rampant flexibility and composability, OR
- retreat into a self-consistent and increasingly irrelevant view of the world.
In both cases, the forces of natural selection are driving towards malleability and “making it work” (even if the answer is approximate). This parallels the loosening of consistency I pointed out when discussing the CAP-conjecture.
It’s a great time to be alive! I can’t WAIT to see what else I am completely wrong about…