Resource-Method-Representation

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned about Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

MVC was created in 1979, in a context of desktop applications with CLI user interfaces and it implied that the UI would be changed automatically if there were changes in the database, caused by some factor external to the user. The same pattern was perfectly usable later on desktop applications with a GUI.

However, its usage in web applications has always been an adaptation because most web applications don’t change the UI as a consequence of changes that happen in the server side, there is always a call from the UI asking the server side for an update of the screen.

I have talked about variants of the MVC pattern before, this post is about another variant: Resource-Method-Representation.

I feel the need to talk about it, not because I find it a key pattern in my practice but because of the misconception that it is the same as the ADR pattern, of which I will write about soon.

2008 – Resource-Method-Representation

The RMR pattern was created by Paul James in 2008 and it adapts the MVC pattern to the context of REST APIs.

Resource

The idea is that the Entities are modelled as REST resources (the first R in the pattern name), with its only public methods mapping to an HTTP method:

	<?php
	// taken from http://www.peej.co.uk/articles/rmr-architecture.html

	class Resource {
	private resourceData = [];
	method constructor(request, dataSource) {
	// load data from data source
	}
	method get(request) {
	return new Response(200, getRepresentation(request.url, resourceData));
	}
	method put(request) {
	return new Response(405);
	}
	method post(request) {
	return new Response(405);
	}
	method delete(request) {
	return new Response(405);
	}
	}

view raw Resource.php hosted with ❤ by GitHub

Method

When a request is made to the API, it is routed to one of these business objects, the Resources, and the method that is called on this resource corresponds to the HTTP method of the request. This method on this business object is then responsible for returning a complete http response including its status code and headers.

Representation

The representation is the Resource representation in a format chosen by the API or requested by the client, ie. JSON, XML, etc.. This representation is the content of the response created by the Method and sent back to the client if/when there is any content to be sent back.

My take on this pattern

The MVC pattern is a presentation pattern, it is a way of separating the model, the domain, from the user interface. That was, and is, the main goal of MVC.

The RMR pattern, however, goes beyond that. It tells us how to design our business objects, our domain entities. More than that, it tells us that our domain entities should reflect the delivery mechanism: the HTTP methods.

This means that this is not just a presentation pattern, it is an architectural pattern as it impacts all layers of the application. It also means that an application built using this pattern is not domain-centric, it is HTTP-centric. Our entities end up having methods reflecting the delivery mechanism instead of domain actions.

I think it might be possible to use this pattern successfully to build small APIs, but I don’t think it can be used for enterprise applications as I believe that enterprise applications require a Domain Driven Design approach, and therefore a domain-centric software development strategy.

Furthermore, I totally agree with Anthony Ferrara when he says:

Not to mention that it couples itself to HTTP so tightly that to try to map it to a CLI or GUI interface would be quite difficult.

Anthony Ferrara 2014, Alternatives To MVC

Sources

2008 – Paul James – Introducing the RMR Web Architecture

2014 – Anthony Ferrara – Alternatives To MVC

Resource-Method-Representation