Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Richardson’s Maturity Model as a tool for understanding not measurement

Recently there’s been a bunch of discussion about Leonard Richardson’s maturity model and how some folks use it as a tool measurement for restfulness. Subbu has a nice post on this here where he says it is basically pointless to use RMM to evaluate restfulness. It encourages folks to build systems with a conformist attitude rather than really evaluating the needs of the system and designing to met those constraints. Mike Amundsen replied saying that he sees value in using RMM from a retrospective sense but not as part of the up-front analysis of a system. If you’ve watched any of my recent talks you may have seen me talk about the Richardson Model. At my talk on REST at DevDays 2011 I spoke about it quite in depth.

A few quick thoughts on RMM

I use RMM as an educational tool to talk about different styles of exposing systems over HTTP as well as the tradeoffs.

For example at Level 0 you are commonly tunneling all traffic over a single HTTP method and a single URI. This means that you lose the benefits of intermediaries like caching severs as you are either not using methods that caching servers care about, or you are using methods they do care about, but in a way that has adverse side effects like poisoning the cache.

There are other tradeoffs with Level 0 like losing visibility in that all the semantics are buried in the payload further pushing constraints on which clients can work with your system. On the benefit side you can say that Level 0 maps very well for doing remote procedure calls as the wire format can map very closely to describing the invocation of a method. Hence the reason it is so widely used.

In the same way you can look at each of the levels and their respective tradeoffs and benefits to help you in thinking through the design of your system.

RMM (in my opinion) is a tool for thinking about design, tradeoffs and benefits, not a checklist.

This entry was posted in REST. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://blogs.msdn.com/gblock Glenn Block

    I agree that is a mistake. A RESTful system can be equally as crappy as an unRESTful system. You could also be going to great lengths to build a RESTful system and you don’t need one. 

  • http://blogs.msdn.com/gblock Glenn Block

    Vasil, REST itself as a definition is pretty clear and hypermedia is defined as part of that definition. But regardless of whether we debate about that or not, the more important quesiton is what are the business constraints of your system and how best to meet them. REST provides a set of benefits and a set of constriants to get there. If you don’t need them, you don’t need REST. If they make sense, then a RESTful architecture style may be appropriate.

  • Vasili Puchko

    I completely agree. Sometimes people even say that if your service doen’t have 2nd (or 3rd? I don’t remember how much levels RMM has) then your service is not RESTful.

  • Anonymous

    The mistake in the way Richardson formulated RMM was to imply that systems with a higher number were inherently better. Of course, using the term “maturity” and assigning numerical values made that inevitable. Which to me is the problem with all *MM methods of looking at systems in that they set up an equivalence between doing more and being better.