Loading ...
Sorry, an error occurred while loading the content.

4422Re: [rest-discuss] Re-using information fields for queries in REST

Expand Messages
  • Seairth Jacobs
    Jun 1 4:54 PM
      "David Orchard" wrote:
      -----Original Message-----
      From: Walden Mathews [mailto:walden@...]
      That looks more like a collection or subset to me.  A single
      artist resource might be more like /Artist/123.  An important
      question is: how does the client discover that URI?  The "hyptertext
      engine" constraint of REST really wants it to be discovered, not
      fabricated by client as a parameter list.
      Why is discovery of a particular URI "better" than discovery of the construction technique for a URI?  This argues that HTML FORM GETs are a bad way of creating URIs because they are fabricated.
      Suppose you defined the semantics of the query response format to provide such constraints/rules necessary to construct URIs.  As long as the client understands the semantics of the format, you are basically where HTML forms are.  However, just listing the URIs themselves would be much more straight forward.  The URI is an opaque identifier.  As such, the client can stay dumb and loosely coupled.  If, at some later time, you should choose to change the URI construction (say from /artist/123 to /artist/tu123 or /a23423992359652), the client continues working unchanged.  The constructed URI approach, on the other hand, would be brittle.  You would either need to construct your URIs in a backward-compatible manner or require the clients to learn the new construction rules, neither of which are a very desirable choice.

      Suppose you want to reference artists on another site that uses an entirely different URI format.  Are you going to reverse-engineer those URIs and add yet more semantics to the query response format for those URIs?

      Also, there's a propensity for humans to see patterns in structures.  URIs are often such a structure.  I agree that a person seeing /artist/123 may be inclined to try artist/124.  However, I think people are more inclined to see /artist?id=123 and try /artist?id=124.  The moment you tell people that there is a pattern, they expect the pattern.  You can't stop people from seeing patterns where there may not be any, but you can certainly stop from telling people there is a pattern where you know there is not one.

      Seairth Jacobs

    • Show all 23 messages in this topic