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

Re: [rest-discuss] Re: Multiple operations on the same ressource

Expand Messages
  • Guilherme Silveira
    Hello Jorn, As you mentioned, If you use the HTTP verbs in a way they were not mean to be used, you break the uniform interface (and create a proprietary
    Message 1 of 28 , Dec 8, 2009
    • 0 Attachment
      Hello Jorn,

      As you mentioned, If you use the HTTP verbs in a way they were not
      mean to be used, you break the uniform interface (and create a
      proprietary extension for the app protocol).
      An exposed resource does not need to be a full representation of what
      you have in your database.

      PUT /user/{username} ==> will update the user information
      PUT /user//{username}/password ==> will update the user'slogin resource
      PUT /user//{username}/contact ==> will update the user's contact resource
      PUT /user//{username}/address ==> will update the user's address resource

      Some stolen comments: "Resources are not storage items (or, at least,
      they aren’t always equivalent to some storage item on the back-end).
      The same resource state can be overlayed by multiple resources, just
      as an XML document can be represented as a sequence of bytes or a tree
      of individually addressable nodes."

      Try not to think as URI <= 1 to 1 mapping => database tables. This is
      one of the typical mistakes people would make with hibernate/ejb in
      the java world in its early days.

      Note that all invocations are idempotent and lockable if you use the
      corresponding http headers.

      Although breaking an internal element into different resource
      representation is fine, I am not sure about opinions on whether there
      can be two ways of POSTING a resource (i.e. POST /user will create the
      user and POST /full_user will create it will its entire
      representation), although I believe its just fine.

      Regards

      Guilherme Silveira
      Caelum | Ensino e Inovação
      http://www.caelum.com.br/


      2009/12/8 Jan Algermissen <algermissen1971@...>
      >
      >
      >
      > Jorn,
      >
      > On Dec 8, 2009, at 8:01 AM, Jorn Wildt wrote:
      >
      > > Thanks for your input.
      > >
      > >> Many RESTafarians frown at doing "partial updates" (i.e. only
      > >> update the
      > >> fields that are actually included in the request body) with a PUT
      > >
      > > Can you say why or point to some online ressource with this debate?
      > >
      > >> For single field updates, this is probably not optimal, but if
      > >> you've got
      > >> different types of state changes that can be initiated by the same
      > >> resource,
      > >> each requiring a different set of data, this is a pretty reasonable
      > >> approach.
      > >
      > > I wasn't really thinking of single fields updates although I can see
      > > my examples are such. Your description "different types of state
      > > changes that can be initiated by the same resource, each requiring a
      > > different set of data" fits my intention quite well.
      >
      > For the update scenario you have three choices:
      >
      > 1) PUT the complete new state (e.g. the whole person
      > representation)
      > 2) PATCH the resource with an appropriate diff
      > 3) POST to an update-processor subresource, e.g.
      > POST /person/3344/updates and have server return
      > 303 See Other
      > Location: /person/3344
      >
      > to tell client that the person resource has changed
      >
      > >
      > > Another example could be a collection where your can POST either a
      > > search query or a new member of the collection.
      > >
      >
      > You need different resources for this because the resource semantics
      > determine the actual 'meaning' of POST. Doing two things that are
      > conceptually different would overload this meaning.
      >
      > Besides - you should use GET for the querying.
      >
      > HTH,
      > Jan
      >
      > > /Jørn
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      >
      > --------------------------------------
      > Jan Algermissen
      >
      > Mail: algermissen@...
      > Blog: http://algermissen.blogspot.com/
      > Home: http://www.jalgermissen.com
      > --------------------------------------
      >
      >
    • Guilherme Silveira
      ... Hello Will, If you add control (action) information within anything else but http headers or verb, you break the uniform interface: the action depends on
      Message 2 of 28 , Dec 8, 2009
      • 0 Attachment

        > One solution is to switch on the posted content type: if it's a

        > "password" then do one thing, if it's a "e-mail" then do something
        > else and so on. This although seems a bit like using the SOAP
        > "action" header and tunneling everyhting through a POST.
        >
        >
        > This is RPC, not a resource system.

        Ok - Why do you say that?

        Hello Will,

        If you add control (action) information within anything else but http headers or verb, you break the uniform interface: the action depends on something that only your system can understand.
        It is not visible to intermediate layers what that request represents.

        Summing up, you lose visibility and you break the uniform interface

        You can create custom proxies that understand this kind of messages, but why do it if you already have the current ones in the real world working for you?

        Regards


      • Jan Algermissen
        ... Not an objection, but something to consider: Splitting a resource into sub resources increases the amount of relationships that need to be understood by
        Message 3 of 28 , Dec 8, 2009
        • 0 Attachment
          On Dec 8, 2009, at 2:10 PM, Bob Haugen wrote:

          > On Mon, Dec 7, 2009 at 11:50 PM, Jørn Wildt <jw@...>
          > wrote:
          >> Another solution is to have one sub-ressource for each operation,
          >> like for instance /users/1234/password, /users/1234/email, /users/
          >> 1234/address - now you know your operation by looking at the
          >> ressource your are posting to.
          >>
          >
          > That's the one I use all the time. I do not understand the objections
          > to it.

          Not an objection, but something to consider:

          Splitting a resource into sub resources increases the amount of
          relationships that need to be understood by client and server. OTH, it
          makes the use of text/plain possible for representing the sub
          resources (and any complex format that can be avoided is one thing
          less to maintain).

          Jan



          > Maybe people are thinking of the /users/1234 resource as a
          > database record. It's just a resource. So is /users/1234/password.
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >

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

          Mail: algermissen@...
          Blog: http://algermissen.blogspot.com/
          Home: http://www.jalgermissen.com
          --------------------------------------
        • Guilherme Silveira
          ... Yes, sorry. ... Agreed... can you give an example on the hyperlinks helping it? (linking from the base resource - which doesnt contain the composite ones -
          Message 4 of 28 , Dec 8, 2009
          • 0 Attachment
            > By 'lockable' you mean 'concurrency controllable', yes? There are no
            > http headers for locking.
            Yes, sorry.

            > Obviously the solution here is to avoid composite resources and stick to
            > hyperlinks only - most people use composite resources, however, because they
            > 'make things easier' and/or it avoids the overhead that comes with the
            > increased number of HTTP requests required.
            > - Mike
            Agreed... can you give an example on the hyperlinks helping it?
            (linking from the base resource - which doesnt contain the composite
            ones - to other resources that can be PUT to or something else?)

            Any reading suggestions with similar examples?

            Thanks Mike,

            Guilherme
          • Bob Haugen
            ... The main resource (or some other entry point) can (and usually does) offer hyperlinks to the subresources.
            Message 5 of 28 , Dec 8, 2009
            • 0 Attachment
              On Tue, Dec 8, 2009 at 7:30 AM, Jan Algermissen <algermissen1971@...> wrote:
              > Splitting a resource into sub resources increases the amount of
              > relationships that need to be understood by client and server.

              The main resource (or some other entry point) can (and usually does)
              offer hyperlinks to the subresources.
            • Philipp Meier
              ... As long as you can agree on a limited set of relation types to the subresources a client must only understand them. One kind of relation would be e.g.
              Message 6 of 28 , Dec 8, 2009
              • 0 Attachment
                "Bob Haugen" <bob.haugen@...> schrieb:

                >On Tue, Dec 8, 2009 at 7:30 AM, Jan Algermissen <algermissen1971@...> wrote:
                >> Splitting a resource into sub resources increases the amount of
                >> relationships that need to be understood by client and server.
                >
                >The main resource (or some other entry point) can (and usually does)
                >offer hyperlinks to the subresources.

                As long as you can agree on a limited set of relation types to the subresources a client must only understand them. One kind of relation would be e.g. "property" for the relation of /user/xxx to /user/xxx/name. "Property" will indicate to the client that the rated resource represents a single property of the linking resource. I'm not sure that this is the best example, but I hope, you get the idea.

                What remains is the task to define a ontology of relation for you resources. I wonder if there is something generic what can be used, e.g. in the rdf or owl ecosystems.

                -billy
                --
                Sent from my Android phone with K-9. Please excuse my brevity.
              • Jørn Wildt
                Does this get through? My two previous messages are lost some where ... (sorry for the noice) /Jørn ... From: Bob Haugen To: rest-discuss@yahoogroups.com
                Message 7 of 28 , Dec 8, 2009
                • 0 Attachment
                  Does this get through? My two previous messages are lost some where ...
                  (sorry for the noice)
                   
                  /Jørn
                   
                  ----- Original Message -----
                  Sent: Tuesday, December 08, 2009 3:47 PM
                  Subject: Re: [rest-discuss] Multiple operations on the same ressource

                   

                  On Tue, Dec 8, 2009 at 7:30 AM, Jan Algermissen <algermissen1971@ mac.com> wrote:
                  > Splitting a resource into sub resources increases the amount of
                  > relationships that need to be understood by client and server.

                  The main resource (or some other entry point) can (and usually does)
                  offer hyperlinks to the subresources.

                • Jørn Wildt
                  ... Sorry, but it seems to me that there is a slight misunderstanding here: I was talking about switching on content type which is a known header. I did
                  Message 8 of 28 , Dec 8, 2009
                  • 0 Attachment
                    > > One solution is to switch on the posted content type: if it's a
                    > > "password" then do one thing, if it's a "e-mail" then do something
                    > > else and so on. This although seems a bit like using the SOAP
                    > > "action" header and tunneling everyhting through a POST.
                    > >
                    > > This is RPC, not a resource system.
                    >
                    > Ok - Why do you say that?
                    >
                    > If you add control (action) information within anything else but http
                    > headers or verb, you break the uniform interface: the action depends on

                    Sorry, but it seems to me that there is a slight misunderstanding here: I
                    was talking about switching on content type which is a known header. I did
                    although compare it to SOAP's action header, so the question is: what is the
                    context for your answer - the content type header or the action header? I
                    guess you are referring to the action header?

                    Switching on content type still seems okay to me - even though I do not know
                    if it makes sense when you take the other answers into account. The feed
                    back so far is mostly: create another ressource to POST to - don't do
                    different POSTs to the same ressource.

                    /Jørn

                    ----- Original Message -----
                    From: "Guilherme Silveira" <guilherme.silveira@...>
                    To: "Mike Kelly" <mike@...>
                    Cc: "Will Hartung" <willh@...>; "Jørn Wildt" <jw@...>;
                    "rest-discuss" <rest-discuss@yahoogroups.com>
                    Sent: Tuesday, December 08, 2009 1:27 PM
                    Subject: Re: [rest-discuss] Multiple operations on the same resource


                    >
                    > > One solution is to switch on the posted content type: if it's a
                    > > "password" then do one thing, if it's a "e-mail" then do something
                    > > else and so on. This although seems a bit like using the SOAP
                    > > "action" header and tunneling everyhting through a POST.
                    > >
                    > >
                    > > This is RPC, not a resource system.
                    >
                    > Ok - Why do you say that?
                    >
                    Hello Will,

                    If you add control (action) information within anything else but http
                    headers or verb, you break the uniform interface: the action depends on
                    something that only your system can understand.
                    It is not visible to intermediate layers what that request represents.

                    Summing up, you lose visibility and you break the uniform interface

                    You can create custom proxies that understand this kind of messages, but why
                    do it if you already have the current ones in the real world working for
                    you?

                    Regards

                    >
                    >
                  • Will Hartung
                    ... No, you re right. I misspoke. It s an interesting idea. The premise is that PUT take a resource representation and performs the update. It does muddy the
                    Message 9 of 28 , Dec 8, 2009
                    • 0 Attachment
                      On Tue, Dec 8, 2009 at 1:07 PM, Jørn Wildt <jw@...> wrote:
                      >> > One solution is to switch on the posted content type: if it's a
                      >> > "password" then do one thing, if it's a "e-mail" then do something
                      >> > else and so on. This although seems a bit like using the SOAP
                      >> > "action" header and tunneling everyhting through a POST.
                      >> >
                      >> > This is RPC, not a resource system.
                      >>
                      >> Ok - Why do you say that?
                      >>
                      >> If you add control (action) information within anything else but http
                      >> headers or verb, you break the uniform interface: the action depends on
                      >
                      > Sorry, but it seems to me that there is a slight misunderstanding here: I
                      > was talking about switching on content type which is a known header. I did
                      > although compare it to SOAP's action header, so the question is: what is the
                      > context for your answer - the content type header or the action header? I
                      > guess you are referring to the action header?
                      >
                      > Switching on content type still seems okay to me - even though I do not know
                      > if it makes sense when you take the other answers into account. The feed
                      > back so far is mostly: create another ressource to POST to - don't do
                      > different POSTs to the same ressource.

                      No, you're right. I misspoke.

                      It's an interesting idea.

                      The premise is that PUT take a resource representation and performs the update.

                      It does "muddy" the concept of a PUT at the detail level. But, from a
                      pragmatic level, it's really much like quibbling over the difference
                      between:

                      UPDATE name SET (firstName, middleInitial, lastName) VALUES
                      (:origFirstName, :origMiddleInitial, :newLastName) WHERE id = :id;

                      and, simply:

                      UPDATE name SET (lastName) VALUES (:newLastName) WHERE id = :id;

                      I think to be pedantic, you would use PATCH instead of PUT for this,
                      but that's just because it seems to have found favor (I don't know the
                      origin for PATCH, as it's not one of HTTP verbs, though WebDAV uses
                      PROPPATCH, so there's likely some inspiration from that).

                      As for the argument about uniform interface, and that using PUT with a
                      fragment doesn't quite comply with that, I'd probably disagree as
                      well, as the uniform interface (i.e. PUT will take the entire resource
                      representation and do the right thing) still exists, this is just an
                      overloading of it.

                      What would be best is that the availability of a "fragment enabled"
                      PUT is discoverable (perhaps via OPTIONS, or some other negotiation
                      protocol), so that clients can degrade gracefully.

                      So, basically, I think a fragment can work well, but I think you
                      should still be able to send the entire resource as well, using the
                      fragments as an optimization for those clients that support it.

                      Regards,

                      Will Hartung
                      (willh@...)
                    • Eric J. Bowman
                      ... What would be the response to a GET request for /person/3344/updates ? -Eric
                      Message 10 of 28 , Dec 11, 2009
                      • 0 Attachment
                        Jan Algermissen wrote:
                        >
                        > 3) POST to an update-processor subresource, e.g.
                        > POST /person/3344/updates and have server return
                        > 303 See Other
                        > Location: /person/3344
                        >

                        What would be the response to a GET request for /person/3344/updates ?

                        -Eric
                      • Justin Cormack
                        ... PATCH just got approved by the IETF, https://datatracker.ietf.org/drafts/draft-dusseault-http-patch/ There is some history in the document - it was in some
                        Message 11 of 28 , Dec 13, 2009
                        • 0 Attachment
                          On 8 Dec 2009, at 21:38, Will Hartung wrote:
                          > I think to be pedantic, you would use PATCH instead of PUT for this,
                          > but that's just because it seems to have found favor (I don't know the
                          > origin for PATCH, as it's not one of HTTP verbs, though WebDAV uses
                          > PROPPATCH, so there's likely some inspiration from that).
                          >

                          PATCH just got approved by the IETF, https://datatracker.ietf.org/drafts/draft-dusseault-http-patch/

                          There is some history in the document - it was in some original drafts.

                          short blog post: http://blog.technologyofcontent.com/2009/12/smart-resources-or-why-you-should-care-about-http-patch/

                          Justin
                        • Will Hartung
                          On Sun, Dec 13, 2009 at 7:29 AM, Justin Cormack ... Thanks for the link Justin. I think the note about server side patching via XSLT or Javascript code is
                          Message 12 of 28 , Dec 14, 2009
                          • 0 Attachment
                            On Sun, Dec 13, 2009 at 7:29 AM, Justin Cormack
                            <justin@...> wrote:

                            > short blog post:
                            > http://blog.technologyofcontent.com/2009/12/smart-resources-or-why-you-should-care-about-http-patch/

                            Thanks for the link Justin.

                            I think the note about server side patching via XSLT or Javascript
                            code is quite novel. It basically turns PATCH in to the similar of an
                            UPDATE SQL statement, where the logic is executed server side.

                            Most UPDATE statements are actually quite simple. But some are not
                            (e.g. UPDATE mytable SET (value) = select thing from othertable WHERE
                            id = 1).

                            Something to think about IMHO.

                            Regards,

                            Will Hartung
                            (willh@...)
                          • Eric J. Bowman
                            ... Ack! Failing to make your messages self-descriptive isn t pragmatic. If I have a distributed hypermedia system, and I want it to gain the benefits of
                            Message 13 of 28 , Dec 17, 2009
                            • 0 Attachment
                              Craig McClanahan wrote:
                              >
                              > Many RESTafarians frown at doing "partial updates" (i.e. only update
                              > the fields that are actually included in the request body) with a PUT
                              > -- I tend towards the pragmatic view and used this in several APIs --
                              > but when you're doing a POST I don't see a reason why it should not
                              > make sense. Letting the client change whatever combination of fields
                              > they need to in *one* request (and therefore probably a single
                              > database transaction) would seem reasonable to me.
                              >

                              Ack! Failing to make your messages self-descriptive isn't pragmatic.
                              If I have a distributed hypermedia system, and I want it to gain the
                              benefits of REST, then falling short of REST in the implementation is
                              anti-pragmatic because what I'm left with is some other architectural
                              style that isn't guaranteed to exhibit the desirable properties I was
                              after when I chose REST to meet them.

                              Consensus on this list for years, has been that PUT is not used for
                              partial updates. While the server isn't required to honor everything
                              in a PUT, for example a server might not change an atom:id even if it's
                              updated in a PUT, this is not some loophole that allows PUT to be used
                              for partial updates.

                              In a REST system, the only thing that matters regarding methods is that
                              they are used according to their definitions. PUT has update-by-
                              replacement (or creation) semantics, PATCH has partial-update semantics
                              and has been in HTTP 1.1 from the beginning (look at the obsolete RFCs,
                              then the comments by RFC 2616's authors about how the lack of inclusion
                              of PATCH was due to time constraints and lack of implementation, but
                              was not meant to suggest that PATCH had been removed from HTTP), and is
                              now reinforced by its own RFC.

                              So, to overlook the method with the required semantics of partial-
                              update (PATCH) and assign those semantics to PUT which has different
                              semantics entirely, is to use PUT other than what it was intended for.
                              This means that out-of-band information is driving your PUT
                              transaction, and the semantics of the interaction are not visible
                              because the messaging is not self-descriptive. Since the semantics of
                              POST are generic, assigning it to cover for PATCH is acceptable. But
                              not PUT -- doing that is failing to apply the uniform interface
                              constraint.

                              -Eric
                            • Solomon Duskis
                              If a user goes to a personal information web page with a whole bunch of forms: 1) update name (textbox + button) 2) update email (textbox + button) 3) update
                              Message 14 of 28 , Dec 18, 2009
                              • 0 Attachment
                                If a user goes to a "personal information" web page with a whole bunch of forms:

                                1) update name (textbox + button)
                                2) update email (textbox + button) 
                                3) update address (textboxes + button)

                                and a user updates only one of those forms (text + button click)... That would still be a legitimate RESTful interaction

                                I don't get the gist of your argument.

                                -Solomon

                                On Thu, Dec 17, 2009 at 5:42 AM, Eric J. Bowman <eric@...> wrote:
                                 

                                Craig McClanahan wrote:
                                >
                                > Many RESTafarians frown at doing "partial updates" (i.e. only update
                                > the fields that are actually included in the request body) with a PUT
                                > -- I tend towards the pragmatic view and used this in several APIs --
                                > but when you're doing a POST I don't see a reason why it should not
                                > make sense. Letting the client change whatever combination of fields
                                > they need to in *one* request (and therefore probably a single
                                > database transaction) would seem reasonable to me.
                                >

                                Ack! Failing to make your messages self-descriptive isn't pragmatic.
                                If I have a distributed hypermedia system, and I want it to gain the
                                benefits of REST, then falling short of REST in the implementation is
                                anti-pragmatic because what I'm left with is some other architectural
                                style that isn't guaranteed to exhibit the desirable properties I was
                                after when I chose REST to meet them.

                                Consensus on this list for years, has been that PUT is not used for
                                partial updates. While the server isn't required to honor everything
                                in a PUT, for example a server might not change an atom:id even if it's
                                updated in a PUT, this is not some loophole that allows PUT to be used
                                for partial updates.

                                In a REST system, the only thing that matters regarding methods is that
                                they are used according to their definitions. PUT has update-by-
                                replacement (or creation) semantics, PATCH has partial-update semantics
                                and has been in HTTP 1.1 from the beginning (look at the obsolete RFCs,
                                then the comments by RFC 2616's authors about how the lack of inclusion
                                of PATCH was due to time constraints and lack of implementation, but
                                was not meant to suggest that PATCH had been removed from HTTP), and is
                                now reinforced by its own RFC.

                                So, to overlook the method with the required semantics of partial-
                                update (PATCH) and assign those semantics to PUT which has different
                                semantics entirely, is to use PUT other than what it was intended for.
                                This means that out-of-band information is driving your PUT
                                transaction, and the semantics of the interaction are not visible
                                because the messaging is not self-descriptive. Since the semantics of
                                POST are generic, assigning it to cover for PATCH is acceptable. But
                                not PUT -- doing that is failing to apply the uniform interface
                                constraint.

                                -Eric


                              • Jon Hanna
                                ... Yes, but if this were done with PUT it would be done by each of them updating a single resource. Doing so may also update part of another resource—there
                                Message 15 of 28 , Dec 18, 2009
                                • 0 Attachment
                                  Solomon Duskis wrote:
                                  >
                                  >
                                  > If a user goes to a "personal information" web page with a whole bunch
                                  > of forms:
                                  >
                                  > 1) update name (textbox + button)
                                  > 2) update email (textbox + button)
                                  > 3) update address (textboxes + button)
                                  >
                                  > and a user updates only one of those forms (text + button click)... That
                                  > would still be a legitimate RESTful interaction

                                  Yes, but if this were done with PUT it would be done by each of them
                                  updating a single resource. Doing so may also update part of another
                                  resource—there may be all manner of interesting relationships between
                                  resources—but each would still be a full update of a URI-identified
                                  resource.
                                • Guilherme Silveira
                                  Hello guys, The question is somehow related so I added in the same thread: If I have a resource (all clients) which is a set of my clients, its hypermedia
                                  Message 16 of 28 , Dec 18, 2009
                                  • 0 Attachment
                                    Hello guys,

                                    The question is somehow related so I added in the same thread:

                                    If I have a resource (all clients) which is a set of my clients, its hypermedia representation either contains only a set of links, a set of links with extra client information or all information with no hypermedia.

                                    The third option does not make sense, I can get it. What about the other two? The first one is a huge set of metadata and the second one is a huge set of metadata with extra client information: updates to the each client resource will affect this resource - loss of visibility?

                                    If, in the second option, every client has its own rel="self" link, then there is no such loss?

                                    Regards



                                    Guilherme Silveira
                                    Caelum | Ensino e Inovação
                                    http://www.caelum.com.br/


                                    On Fri, Dec 18, 2009 at 9:45 AM, Jon Hanna <jon@...> wrote:
                                     

                                    Solomon Duskis wrote:
                                    >
                                    >
                                    > If a user goes to a "personal information" web page with a whole bunch
                                    > of forms:
                                    >
                                    > 1) update name (textbox + button)
                                    > 2) update email (textbox + button)
                                    > 3) update address (textboxes + button)
                                    >
                                    > and a user updates only one of those forms (text + button click)... That
                                    > would still be a legitimate RESTful interaction

                                    Yes, but if this were done with PUT it would be done by each of them
                                    updating a single resource. Doing so may also update part of another
                                    resource—there may be all manner of interesting relationships between
                                    resources—but each would still be a full update of a URI-identified
                                    resource.


                                  • Eric J. Bowman
                                    ... No, what the server does is supposed to be opaque behind a uniform interface. Don t worry about visibility beyond the uniform interface -- the server can
                                    Message 17 of 28 , Dec 19, 2009
                                    • 0 Attachment
                                      Guilherme Silveira wrote:
                                      >
                                      > Hello guys,
                                      >
                                      > The question is somehow related so I added in the same thread:
                                      >
                                      > If I have a resource (all clients) which is a set of my clients, its
                                      > hypermedia representation either contains only a set of links, a set
                                      > of links with extra client information or all information with no
                                      > hypermedia.
                                      >
                                      > The third option does not make sense, I can get it. What about the
                                      > other two? The first one is a huge set of metadata and the second one
                                      > is a huge set of metadata with extra client information: updates to
                                      > the each client resource will affect this resource - loss of
                                      > visibility?
                                      >

                                      No, what the server does is supposed to be opaque behind a uniform
                                      interface. Don't worry about visibility beyond the uniform interface
                                      -- the server can do whatever it wants. Besides, if you're defining a
                                      resource as a list of links to client-specific resources, plus client
                                      information derived from those client-specific resources, then the fact
                                      that changing a client-specific resource may change the resource up one
                                      level in a hierarchy should be readily apparent. But that's usability,
                                      not invisibility.

                                      >
                                      > If, in the second option, every client has its own rel="self" link,
                                      > then there is no such loss?
                                      >

                                      My rule of thumb, is not to use rel='self' unless you need it
                                      programatically, for some reason. In case the document is saved
                                      without its original request URI, it should still work, which is why I
                                      like to use a <base> or xml:base href, plus relative URLs within the
                                      document. If the document is loaded from disk using the 'file://' URI
                                      scheme, it leads the user right back into the flow of the application.
                                      So I don't see much purpose for rel='self'.

                                      -Eric
                                    Your message has been successfully submitted and would be delivered to recipients shortly.