1. 1

  2. 3

    I’ve seen a bunch of good rants and teardowns of RESTy stuff…this isn’t even a good rehash of those arguments.

    api is incorrect, since this doesn’t really explore API design beyond “zomg rest urrrrgh”.

    historical is incorrect, since this doesn’t really talk about anything of historical relevance. A comparison of, say, REST-as-thesis with prevailing design patterns would be a good fit. An over-time discussion of the evolution of REST from thesis to modern practice would be a good fit. This is neither of those things.

    1. 1

      The trouble with Fielding’s paper is it is describing some very detailed concepts that have lots of fine fine print.

      Almost nothing fits into a marketing slogan nor a bloggy rant.

      I’m convinced Fielding is onto something important.

      I’m equally convinced that he hasn’t distilled it down to a succinct and well justified core.

      So yes, it is easy to poke holes in REST…. if ignore the fine print.

      It is equally easy to throw the baby out with the bath water.

      There are some very sweet fruits that come with the REST architectural style if you are paying close attention.

      Alas, as always with any architecture. It’s fragile.

      All you need is some asshat to insist you violate the architectural principles to meet some short term business goal….. and you’re shepherding a world of pain.

      Then people get confused and blame the architecture instead of the asshat.