One Method Too Few or Too Many?

Ethan Fremen writes in a lesscode comment...

The main way in which the additional verbs are really helpful in an application is whenever you want to manipulate multiple resources at once. Of course, in most cases where you’re doing that, you’re using even more of those ‘useless’ verbs, like MKCOL and PROPFIND etc.

To me it’s like you’re arguing that the only methods anyone ever needs on a class are gettr and settr methods.

I don't think the comparison with an object-oriented programming language is helpful. Classes with only getters and setters are brittle in their context (very small amount of state that changes often, very closely located to collaborating objects within a single OS process, one or a few developers working together modify most of those classes, short release cycles).

On the other hand with a distributed system it may be that the more methods in a system the more brittle in that context (very large amount of state that does not change often, very remotely collaborating systems across multiple network boundaries, many developers who know little if anything of each other, long release cycles)

A mechanism to "manipulate multiple resources at once" in the latter, distributed HTTP context may be to construct a resource that represents the collection of resources and then manipulate *that* resource using the smaller number of verbs.

The hurdle I've mostly climbed over to the level I currently understand REST, HTTP, URIs, Atom, etc. is that this is not an object system. This is an application protocol (and architecture, formats, etc.) for distant collaboration. The challenge is to understand what are the conceptual pieces in this system and how to map ones needs into this system.

Most of the heavy computational lifting of those resources *does* take place in object systems (or functional or...) where there is a rich processing vocabulary. The distributed part is just about moving representations around in a coordinated fashion to enable the heavy compuational lifting at the appropriate time and place. The architecture for one is most likely not going to serve the characteristics of the other. The more they are considered distinct the better.

That said, I cannot clearly articulate when to create a new method except that the resistence to adopting that new method will be great so the time spent thinking about how to use the existing methods will more likely be the time well spent.

My second articulation would be to suggest that if you want to create a new method or two, then probably so do I and so do several others reading this. Before long we would be drowing in a sea of new methods. There may be a Cambrian Explosion of new collaborative techniques if we focus on how better to combine the pieces we already have. Inventing another nucleotide should be a very high bar.

Update:

In another lesscode comment Paul James confirms this approach...

You don’t need new verbs to manipulate multiple resources at once, you just need another resource that represents all the resources you want to manipulate together and to then manipulate that with your existing verbs.