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

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

Expand Messages
  • Peter Williams
    On Wed, Sep 30, 2009 at 1:00 AM, Jan Algermissen ... I like the direction of this idea. The idea of the hypermedia context as a nameable concept might remove
    Message 1 of 44 , Sep 30, 2009
      On Wed, Sep 30, 2009 at 1:00 AM, Jan Algermissen
      <algermissen1971@...> wrote:

      > I am thinking about using "hypermedia context"[1] for the notion of the
      > acquired linking (and document appearance) knowledge about a resource.
      > For example, when a client comes across a <collection> element in an
      > Atom Pub service document and if that <collection> includes a category
      > foo then the resource the <collection> element refers to is known by
      > the client to be in that certain 'hypermedia context'.
      > A specification could name the described context as 'the foo
      > collection'.
      > 'Hypermedia context' emphasizes that the 'classification' is all about
      > how the resource appears in the client's built-up applicaton state.
      > I am not quite there yet, but I think there are interesting ways to
      > formalize 'hypermedia context' as a set of individual 'link tests' that
      > evaluate to true. E.g. if have-link(x , 'edit-media', y) then y "can be
      > used to modify a Media Resource associated with that Entry"[2]
      > It also touches on the idea of duck typing[3].

      I like the direction of this idea. The idea of the hypermedia context as a
      nameable concept might remove the necessity to even informally think
      about the type/category/flavor of the resources.

      Are hypermedia contexts a way to categorize (potential) application
      states by the transition links and information available at that

      Peter Williams
    • Jan Algermissen
      Stefan, [yet another late reply to this one :-)] ... What about thinking about this in terms of kinds of application states ? Resources represent application
      Message 44 of 44 , Dec 9 1:10 AM

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


        > 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
      Your message has been successfully submitted and would be delivered to recipients shortly.