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

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

Expand Messages
  • Stefan Tilkov
    ... But awol:Feed and awol:Entry are owl:Class, right? If so, it appears that your answer to my question would be class (I am aware that this means
    Message 1 of 44 , Sep 3, 2008
      On 03.09.2008, at 17:56, Story Henry wrote:

      Use RDF then you don't get in a muddle about which words to use. Here  
      in N3 with a mathematical theory to back you, you can say:

      @prefix awol: <http://bblfish.net/work/atom-owl/2006-06-06/#> .

      <http://yourdomain.com/postings/> a awol:Feed .
      <http://yourdomain.com/postings/1234> a awol:Entry .

      But awol:Feed and awol:Entry "are" owl:Class, right? 
      If so, it appears that your answer to my question would be "class" (I am aware that this means something different than a type). Right?

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