Herberto Gra\u00c3\u00a7a, as part of his Software Architecture Chronicles, saw fit to review the Action-Domain-Responder pattern that I have written so much about. It\u2019s a good writeup, and you should read the whole thing, but it is off in a couple of places. I sent Herberto a followup email with some minor corrections and clarifications; I repeat it below (with light editing) for posterity.
\n\n\nThe ADR pattern was created by Paul M. Jones
\n
I prefer to say, not that I \u201ccreated\u201d the pattern, but that I \u201crecognized and named\u201d it in 2014. Slim, for example, already had single-action controllers at that time, and the various Domain Logic patterns previously existed as well. If I \u201ccreated\u201d anything, it was the idea of the Responder; that is, of treating the Response-building work as a completely separate concern. But even that is just an application of Separated Presentation.
\n\n\nto adjust MVC to the context of web REST APIs.
\n
APIs were one aspect, but the origin was more in the typical HTML page-based interface. For example, the word \u201cAction\u201d in Action Domain Responder was inspired both by \u201caction\u201d methods in Controllers, and by the \u201caction\u201d attribute on <form> tags in HTML interfaces.
\n\nbecause the idea is to adapt the MVC pattern to the context of an HTTP REST API, the Action (Controller) names are mapped to the HTTP request methods so we will have Actions with names as Get, Post, Put, Delete
\n
Well, you can do that, but it\u2019s not strictly necessary. I think it would be more accurate to say that it\u2019s typical for an Action to be mapped to a route, and for the routes themselves to be mapped to GET/POST/PUT/DELETE etc.
\n\n\nAs an organization pattern, all Actions on a resource should be grouped under a folder named after the resource.
\n
That is one reasonable approach, but it\u2019s not dictated by ADR. Alternatively, instead of grouping Actions by resource, you might organize them by Use Case, or by the intended Interactions with the underlying application.
\n\n\nThis pattern was thought of specifically for REST APIs, so in this form it is not refined enough to be used in web applications with an HTML interface (ie. what would be the name of the action to show a form, prior to creating a resource?) \u2026 I think the pattern can easily be extended so that it is fully usable with an HTML interface: We can emulate some extra HTTP methods specifically to handle the HTML requests that a REST API does not have.
\n
Given my notes above, I think it\u2019s fair to say that new HTTP methods are not really needed. What is needed, as Herberto already points out, is a way to \u201cshow a form prior to creating a resource\u201d (among other things).
\nBecause the Actions do not necessarily map one-to-one with HTTP methods, it\u2019s easy enough to specify that GET /{$resource}/new (or something similar) routes to an Action that gets default values for that resource from the Domain, then hands off to a Responder that builds the form HTML. You can see an example of that here:
BlogAddAction presents the form with default values
\nBlogCreateAction actually creates the resource, or redisplays the form on error.
\nYou might route the first as GET /blog/new and the second as POST /blog. (That idea appears to originate from Ruby on Rails and has been imitated elsewhere.)
Aside from those notes, Herberto\u2019s article is a fair summary and description of ADR. I\u2019m glad he put it together.
\nYou can read more about Action Domain Responder at http://pmjones.io/adr.
\n" }