How do you measure the RESTful-ness of an application?

| by Mark Little Follow 14 Followers on May 15, 2011. Estimated reading time: 5 minutes |

Over the past few years it would be hard to ignore the rise in popularity for using RESTful approaches to building enterprise applications. Now we seem to have moved beyond the REST vs WS-* debates, or whether or not REST and SOA are complimentary, to discussions around the maturity of REST-based implementations. Unfortunately it seems that even this could be an active area of confusion, debate and disagreement. When discussing maturity and REST in the same sentence, some individuals refer to the Richardson Maturity Model as the right approach to measure against. For instance, in his recent article Martin Fowler discusses the various levels in the model:

  • Level 1: Introducing the concept of Resources into your architecture.
  • Level 2: Supporting HTTP verbs.
  • Level 3: HATEOAS.

As Martin states:

I should stress that the [Richardson Maturity Model], while a good way to think about what the elements of REST, is not a definition of levels of REST itself. Roy Fielding has made is clear that level 3 [Richardson Maturity Model] is a pre-condition of REST.

And Martin goes on to refer to a conversation he had with Ian Robinson that helped to put the model into context for them both:

  [Ian] stressed that something he found attractive about this model [...] was its relationship to common design techniques.
  • Level 1 tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources.
  • Level 2 introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation.
  • Level 3 introduces discoverability, providing a way of making a protocol more self-documenting.
The result is a model that helps us think about the kind of HTTP service we want to provide and frame the expectations of people looking to interact with it.

But although this model appears to have some support, there are differences of opinion in the REST community. For instance, in this article, which also refers to Roy's discussion on what makes a RESTful system, the author states:

So, by Roy’s strict criteria, hypermedia is a *precondition* of REST. Anything else should not call itself REST. So the maturity model actually looks like this:
  • Level One : not REST
  • Level Two : not REST
  • Level Three : REST

However, one of the commenters points out that:

The thing is, if you miss out *any* of the [maturity] levels, you end up with something that isn’t REST (although I’d replace “HTTP verbs” with “a small set of predefined, globally agreed verbs”). In terms of implementation, you can’t be at level 3 without having gone through level 1, so I think the order makes sense.

And now Subbu Allamaraju, author of the RESTful Web Services Cookbook, enters the debate with a recent article on using the Richardson Maturity Model. In fact he states up front that the model should not be used to determine the RESTful-ness of an application. As he states:

Judging an app based on what REST constraints it supports and not based on whether it chose the right constraints to meet the desired quality attributes is a pointless exercise. It is like criticizing an application because it chose to use an RDBMS and not a NoSQL store without looking at the qualities that lead to that choice. It is equally silly to conclude that your RESTful app achieved the "glory of REST" with its choice to use the hypertext constraint – what matters is whether it met any ilities that matter for that app.

This created an interesting back-and-forth on the comments section of the article. For instance, Mike Amundsen states:

While I would agree that it is a mistake to assume that an implementation that adheres to the Fielding’s REST constraints is automatically the right implementation for a given task, I do not accept the assertion that the very act of assessing an implementation’s adherence to a set of constraints (per REST, C2, etc) is “a pointless exercise” or “silly.” [...] what is the message you want to convey here? IOW, why _not_ assess compliance? - what do you _not_ get from assessment that you think is important? - what do you get from assessment that is _not_ helpful? is there something misleading that comes form assessment? are there some assumptions buried in the act of assessment that are dangerous? misleading? unhelpful?

And follows up with his own interesting entry on the merits of determing the RESTful-ness of an application versus the usefulness of using REST for the application in the first place.

Subbu answers Mike's original comment with:

Assessment needs to have a context, and quality attributes provide that context. Assessment just around REST’s constraints may lead to poor/questionable decision making. [...] there is no universal goodness criteria.

To which Mike responds:

i think i see your POV. You are talking about early stage implementation behavior: “I will build a Web app today; these are the constraints I will use (because Fielding sez so, etc.).” In the case above, focusing on meeting some set of “constraints” is improper. As you would say, early work should focus on the “ilities” you wish to support. I assume then that you would still agree that _after_ identifying the qualities, it makes sense to select constraints that promote those qualities in the implementation (as Fielding does in his diss).

Later on in the comments, Ian Robinson enters the debate, where he agrees that it may be unwise to use Richardson's model blindly:

[...] Leonard originally created his heuristic to help developers understand REST – that’s all. He does so by drawing analogies between some general and familiar software development practices (e.g. divide-and-conquer; do-the-same-old-same-old-things-in-the-same-old-same-old-way) and the application of Web technologies (give everything its own address, use HTTP the way it was intended to coordinate the transfer of representations).

And elsewhere Guilherme Silveira, the author of Restfulie, is looking to build on and extend Richardson's model to produce 5 steps towards REST Architecture Maturity, which unlike Richardson's model is not tied to HTTP.

  • Step 1: determine and use uniform interfaces.
  • Step 2: use linked data to allow a client to navigate through a resource's state and relations.
  • Step 3: add semantic "value" to the links.
  • Step 4: create clients "in a way that decisions are based only in a resource representation relations, plus its media type understanding".
  • Step 5: "code on demand teach [sic] clients how to behave in specific situations that were not foreseen, i.e. a new media type definition."

So is this 5 step approach better? Does it address the concerns of Subbu and others who state that the original model should not be used slavishly? Or is there a better approach out there?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

The next step in REST: standards, commities, compliance finally SOAP by Robert MacLean

I am not a fan of this idea of trying to define what is REST and what is not, because it will lead to a standard which means a committee is in there somehow. Next features be added and soon, well I suspect we will have SOAP in a REST skin.

That said, despite not being a fan (and being pessimistic) I too have done the maturity model of REST. Why would I do this? My goal is not to show mine is REST and yours is not, but rather as a teach aid. Learn basics, then grow, and grow etc…
You can see it at:

Follow what the Web does, then go off and do some real work by Duncan Cragg

Forget all this maturity model stuff - it scares people.. :-)

Just use the simplest pattern that works for you - ideally just follow what the Web does - then go off and do some real work instead of worrying.

Here was my own contribution to the debate - Mature REST In Six Lines!.

It's easy. by Mark Nottingham

I've had developers call me in the dead of (their) night, tearing their hair out because they want to make their app "more RESTful" but they don't know how. IMO it's an absolutely useless goal.

Build applications that meet your requirements, using the tools at hand. If you do so in a way that leverages existing protocols (HTTP) and tools (implementations), and gives you more value, great. If you don't know enough about your craft to make informed decisions, learn more about them; don't take a side trip and get an architecture degree.

See also:
which may (or may not) be helpful to those with RESTy questions.

Re: It's easy. by Brian Paxton

I have to agree. It all comes down to business value for me. The KISS principle gets easily forgotten in the definition of maturity models and specifications and you start to include more and more content as new ideas emerge. This can often lead to you over engineering and loosing sight of the original problem.

Keep things simple and leverage existing collateral appropriately

Reasons for *not* determining RESTful-ness? by Mike Amundsen

I must say, so far the case for *not* asking if implementations are RESTful seem to be:
"it's silly", "a pointless exercise" - Subbu
"it scares people." - Cragg
"developers call me in the dead of (their) night, tearing their hair out", "absolutely useless" - Nottingham

These comments strike me as based on emotions and highly subjective. Is this really the only objections we have?

After several attempts I *was* able to get this from Subbu:
"Assessment just around REST’s constraints may lead to poor/questionable decision making." (emphasis mine)

That seems to me like a start at some reasoned opinion about the topic, but still falling short of being helpful (the just qualifier renders the point almost useless in any discussion).

I suspect there is more going on here; that this "hating" on RESTfulness assessments is just a proxy for some other issue(s).

  • Is the point here that Fielding's work is just not relevant? Not applicable to anyone implementing Web solutions?

  • Is the point here that people are abusing Fielding's work as a way to denigrate or devalue other's efforts?

  • Is the point here that people are mis-understanding or mis-applying Fielding's work and, as a result, sowing FUD, etc.?

IOW, I am asking here if there is something fundamental about Fielding's work that is harmful to the Web and should be avoided or, on the other hand, there is something about the way in which people talk about or apply Fielding's that is unhelpful or harmful. The comments here do not seem to make that distinction at all.

I'm all in favor of improving the state of knowledge about designing, implementing, and maintaining solutions for distributed networks. To date, I've found using Fielding's work as a guide helpful not just to me but to others from whom I have learned and to those who ask me questions. If the folks commenting on this thread are saying that there are other, better ways to look at existing work, analyse the value there, and apply it to future work, I'd like to hear about it.


Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you