in Uncategorized

Measuring REST

This thought is long overdue. I wanted to write this up nearly a year ago. Since there are more interesting problems to work on than the subject of this post, let me keep this brief.

Don’t follow models like Richardson’s Maturity Model to decide whether your app is RESTful or not.

Why not? The reason is quite simple. We build software to do something of value while accounting for some quality attributes (or "ilities"). In the case of RESTful apps, how you prioritize a given set of quality attributes can help you choose the right set of constraints. Period. 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.

Update: In addition Jeromy’s blog post in his comment below, see him explain in this video.

Write a Comment

Comment

24 Comments

    • It should not matter. If it is a public service, then public is a stakeholder and that should influence the prioritization of quality attributes. But I don’t think “I want to achieve REST glory” is a quality attribute. “Interoperability with the Web” is the right quality attribute to weigh in that case.

  1. I totally agree with this. I think that on a more general level, blind following of some prescriptive model is bad thing… unless you’re a large business trying to get some industry certification.

  2. 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.”

    http://amundsen.com/blog/archives/1098

      • instead of labeling the act, 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?

        • 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. As Jeromy points out, there is no universal goodness criteria.

          • Well, that’s the actual debatable part. Of course there is no universal goodness criteria – only analytical statements are universal (Kant)!! But to most, many, REST constraints are, and should be, at the top of their goodness criteria. That’s fine since that’s a behaviour based on experience and know-how. Honestly, making a statement such as that decision making is relative is a tautology.

          • hmm….

            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).

            In my narrative, I am talking about post-mortem assessments; Looking at existing implementations. In post-implementation review, it is extremely difficult to locate the “ilities” in the design, but easier to locate the “constraints” employed; I can identify the constraints and derive the qualities.

            As for “universal goodness (per Jermoy), I make no quarrel. The work I do right now is focused on helping people locate and understand the impact of constraints on systems (post-implementation) and take that knowledge and apply it (pre-implementation) to new designs.

            Linking qualities to the constraints (per Fielding[1]) is, IMO, a valid approach.

            [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3_4

  3. @Bruno

    “But to most, many, REST constraints are, and should be, at the top of their goodness criteria.”

    I totally agree. But I would not use RESTfulnessas the way judge design decisions. To me that’s like organized religion.

  4. @Mike:

    “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.).”

    Not just that. I continue to be concerned about the routine statements people make about level of conformance.

    “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).”

    Exactly. Most people start reading about constraints before understanding about the ilities that lead to those constraints, and this needs to change.

    “Linking qualities to the constraints (per Fielding[1]) is, IMO, a valid approach. ”

    IMV, that is the only rational approach to take.

  5. I just wrote on the “REST Architects” group on LinkedIn something I titled “Classification of REST by “scenarios” where it can be eventually applied” where I cited this post, although is not directly related to it. If someone cares to read it, comments are welcome.

    The group is here [1] but I think it’s not a open group.

    http://www.linkedin.com/groups?mostPopular=&gid=151744

  6. Hi Subbu

    While I’m probably more culpable that most in promoting the RMM, I too am wary of using it as an assessment model. I’d remind readers that 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).

    I’d encourage everyone to go look at Leonard’s presentation from QCon 2008 where he first proposed the heuristic: http://www.crummy.com/writing/speaking/2008-QCon/

    Kind regards

    ian

  7. I agree with the statements here that RMM should not be a general assesment tool. I use RMM to talk about the different styles of building systems over HTTP. I then talk about the tradeoffs / benefits of each level. For example when you are at level 0 you are using the same method for everything thus shutting out intermediaries. You also may be violating semantics of HTTP for example if all your methods are GET!

  • Related Content by Tag