Every Noun Can Be Verbed…

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…

— Pat

Comments (2)

  1. fuzzyBSc says:

    I think that the application of business logic to CRUD-submitted or REST-submitted data is absolutely the norm. It is easy to confuse the concepts of REST as an interface control model and a database-like relational implementation. It is the interface between components of the architecture that REST attempts to reign in. What a service chooses to do with its own data is its own prerogative.

    While the discussion of nouns and verbs is easy to understand initially, I think it is an ultimately unsatisfying dichotomy. I take a more protocol-oriented approach, separating object identification, interaction and content. A GET interaction, for example, is not simply a noun or a method. A GET interaction incorporates protocol information such as headers, and I think also really incorporates possible response messages. Messages are exchanged between an anonymous client and identified resource object. REST ultimately says that it is valuable to separate the set of objects, the set of interactions that can transfer content between clients and objects and the set of content types that are transferred. It says that these should be decoupled so that they can evolve separately.

    It isn’t really a clash between nouns and content types. It is a clash between uniform interactions with a set of objects and non-uniform interactions with a different set of objects. Non-uniform interactions can be folded onto a smaller set of objects, but doing so harms interoperability and evolvability of interactions.

    I think it is the decoupling of interaction and content that really separates REST from traditional SOA and from traditional CRUD. Traditional SOA makes content subordinate to interactions, by placing parameter lists within the definition of its methods. That means that the total number of methods will equal the number of interactions x the number of content types, and may be multiplied out by the number of identifiers also. This reduces the overall feasibility of a uniform interface. Traditional CRUD decouples method and content type, but relies on atomic content combined with transactions. REST tends to rely on higher-level content types, such as HTML or more semantic-intensive content types. This reduces the reliance of REST on transactions and stateful interaction.

    REST walks a middle line between traditional CRUD and traditional SOA, hopefully obtaining the benefits of CRUD’s interoperability as well as SOA’s technology independence, plus many of its own benefits.