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

14107Re: [rest-discuss] Terminology: "Resource Types"?

Expand Messages
  • Jan Algermissen
    Dec 9, 2009
    • 0 Attachment
      Stefan,

      [yet another late reply to this one :-)]

      On Sep 2, 2008, at 11:04 AM, Stefan Tilkov wrote:

      > On 02.09.2008, at 08:59, Roy T. Fielding wrote:
      >
      >> On Sep 1, 2008, at 10:41 PM, Stefan Tilkov wrote:
      >>> What do you call the concept of "classes" or "types" of resources in
      >>> your RESTful designs? E.g. when you decide to turn each "customer"
      >>> into its own identifiable resource - http://example.com/customers/
      >>> 1234
      >>> - what does http://example.com/customers/{id} describe? Both
      >>> "resource
      >>> class" and "resource type" would work, but don't seem really
      >>> convincing.
      >>>
      >>
      >> We call them resources. If they had types, they would be strongly
      >> coupled to whatever expected that type.
      >>
      >> ....Roy
      >
      > I don't want to suggest there's this kind of coupling (in fact I view
      > the lack of it as a strength, and this is why I'm unhappy with
      > "type"). What does the template identify? Resource, obviously, but
      > also a "group of similarly identified resources"?
      >
      > It's not really the URI template connection I'm concerned with, I just
      > wonder whether there's a better term than "kind of …", as in "The
      > first step in designing an application interface should be to identify
      > the different kinds of resources you want to expose."

      What about thinking about this in terms of "kinds of application
      states"? Resources represent application states that the client can
      transition to. In M2M interactions the client code is a manifestation
      of the assumptions the client (developer) makes about the application
      state it reaches at a certain point.

      When I code a client for an ordering service, there will be (in some
      way) the coded assumption that after submitting an order there will be
      an application state that represents the order and (most importantly)
      provides the next transitions for 'operations' on that order (order
      change, order cancelation).

      I understand this in the sense that the client expects a certain "kind
      of application state" and this expectation corresponds to the reason
      why the server "exposes certain kinds of resources".

      Despite the fact that all resources are just resources this client
      side expectation about the next available transitions (which is what
      the "kind of application state" essentially means) is just not going
      to go away.

      Jan



      >
      > Thanks,
      > Stefan
      > --
      > Stefan Tilkov, http://www.innoq.com/blog/st/
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >

      --------------------------------------
      Jan Algermissen

      Mail: algermissen@...
      Blog: http://algermissen.blogspot.com/
      Home: http://www.jalgermissen.com
      --------------------------------------
    • Show all 44 messages in this topic